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

On Fri, May 11, 2012 at 9:55 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On fre, 2012-05-11 at 09:26 +0200, Magnus Hagander wrote:
>> On Thu, May 10, 2012 at 6:28 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> > On tor, 2012-05-10 at 17:31 +0200, Magnus Hagander wrote:
>> >> If people want the main docs building more often that's not really a
>> >> problem other than time - we just need to decouple it from the
>> >> buildfarm and run a separate job for it. It's not rocket science..
>> >
>> > Many years ago, Bruce and myself in particular put in a lot of work to
>> > make the turnaround time on the docs build less than 5 minutes, based on
>> > various requests.  I'm disappointed to learn that that was abandoned
>> > without discussion.  We might as well just put the old job back.
>>
>> It was not "abandoned without discussion" in any way.
>>
>> First of all, the docs still build in 5 minutes.
>
> That is different from the turnaround time from the commit.
>
>> Second, the "5 minutes docs build" link on the website was removed in
>> *2007*. At the request of Bruce, who maintained it. This request was
>> (at least according to the commit message and form what I can
>> remember) made in public on pgsql-www, and thus clearly open for
>> discussion. At http://archives.postgresql.org/pgsql-www/2007-12/msg00212.php.
>> Where Bruce claims the other one runs often enough, and nobody
>> objects.
>
> You are misinterpreting this.  The reason Bruce's link was removed was
> that the other (official) build was set to run at the same frequency, so
> Bruce's build was exactly redundant.  The requirement/aspiration to have
> a few minutes turnaround time continued.

But the other (official) build was *not* set to run at the same
frequency. It was set, according to that mail, to run frequently
enough, but it did not run every 5 minutes. at least not the only
cronjob I found back then.


>> Third, the regular docs build on the developer box (which I think ran
>> once / hour?) *did not work* (prior to that it kind of work but often
>> hung and failed, but at least it tried to run - at this point it
>> stopped even trying).
>
> If you had any problems with how well they worked, we could have
> discussed this.  It's fine if you want to change how they run, and I
> have no problem with how they are run now, but I just want to make clear
> what requirements led to the setup at the time.

The entire machine they ran on *died*. Because it had been
unmaintained for many years. and parts was silently upgraded where as
other, incompatible, parts were not. We did actually leave the script
around. It ran for months, failing at step one, and pretty much nobody
complained.

The docs build was *entirely* undocumented (other than the official
cronjob which did *not* run every 5 minutes, but I guess you are
saying there was a second, undocumented, cronjob that ran more often).


But in the interest of actually being productive - what *is* the
usecase for needing a 5 minute turnaround time? I don't buy the "check
what a patch looks like", because that should be done *before* the
commit, not after - so it's best verified by a local docs build anyway
(which will also be faster).

I'm sure we can put something in with a pretty quick turnaround again
without too much strain on the system, but it does, as I mentioned
before, require decoupling it from the buildfarm which means it's not
just tweaking a config file.

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