Horton

Re: Draft release notes complete

Peter Eisentraut <peter_e@gmx.net>

View thread
From: Peter Eisentraut <peter_e@gmx.net>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Magnus Hagander <magnus@hagander.net>, Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-09-05T22:13:21Z
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 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 ... ?

> And the old script often broke badly, IIRC.

The script broke on occasion, but the main problem was that it wasn't
monitored.  Which is something that could have been fixed.

> The current setup doesn't install
> anything if the build fails, which is a distinct improvement.

You mean it doesn't build the docs if the code build fails?  Would that
really be an improvement?