Re: Draft release notes complete - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: Draft release notes complete
Date
Msg-id 504CE575.2050607@kaltenbrunner.cc
Whole thread Raw
In response to Re: Draft release notes complete  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Draft release notes complete  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 09/06/2012 12:13 AM, 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 ... ?
> 
>> 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?

why would we want to publish docs for something that fails to build
and/or fails to pass regression testing - to me code and the docs for it
are a combined thing and there is no point in pushing docs for something
that fails even basic testing...


Stefan



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: build farm machine using mixed results
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: Draft release notes complete