Horton

Re: Draft release notes complete

Magnus Hagander <magnus@hagander.net>

View thread
From: Magnus Hagander <magnus@hagander.net>
To: Andrew Dunstan <andrew@dunslane.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-07T13:57:11Z
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 Thu, Sep 6, 2012 at 1:06 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> On 09/05/2012 06:13 PM, Peter Eisentraut wrote:
>>
>> On 8/29/12 11:52 PM, Andrew Dunstan wrote:
>>>>>
>>>>> Why does this need to be tied into the build farm?  Someone can surely
>>>>
>>>> set up a script that just runs the docs build at every check-in, like it
>>>> used to work.  What's being proposed now just sounds like a lot of
>>>> complication for little or no actual gain -- net loss in fact.
>>>
>>> It doesn't just build the docs. It makes the dist snapshots too.
>>
>> Thus making the turnaround time on a docs build even slower ... ?
>
>
>
> 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?


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/