Re: Draft release notes complete

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Magnus Hagander <magnus@hagander.net>
Cc: Peter Eisentraut <peter_e@gmx.net>, Alvaro Herrera <alvherre@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-09-07T16:50:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Expose track_iotiming information via pg_stat_statements.

  2. Rewrite GiST support code for rangetypes.

  3. Clean up a couple of box gist helper functions.

  4. Replace the "New Linear" GiST split algorithm for boxes and points with a

On 09/07/2012 09:57 AM, Magnus Hagander wrote:
> On Thu, Sep 6, 2012 at 1:06 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>>
>> A complete run of this process takes less than 15 minutes. And as I have
>> pointed out elsewhere that could be reduced substantially by skipping
>> certain steps. It's as simple as changing the command line in the crontab
>> entry.
> Is it possible to run it only when the *docs* have changed, and not
> when it's just a code-commit? meaning, is the detection smart enough
> for that?
>
>


There is a filter mechanism used in detecting is a run is needed, and in 
modern versions of the client (Release 4.7, one version later than 
guaibasaurus is currently using) it lets you have both include and 
exclude filters. For example, you could have this config setting:

     trigger_include => qr(/doc/src/),

and it would then only match changed files in the docs tree.

It's a global mechanism, not per step. So it will run all the steps 
(other than those you have told it to skip) if it finds any files 
changed that match the filter conditions.

If you do that you would probably want to have two animals, one doing 
docs builds only and running frequently, one doing the dist stuff much 
less frequently.


cheers

andrew