Re: [COMMITTERS] pgsql: update files for beta3 - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: [COMMITTERS] pgsql: update files for beta3
Date
Msg-id 87pryav8rv.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: update files for beta3  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
"Magnus Hagander" <magnus@hagander.net> writes:

> On Fri, Nov 16, 2007 at 09:04:38AM +0100, Peter Eisentraut wrote:
>> Yeah, I think it's a bit insane.  Keeping a few Autoconf versions around isn't 
>> hard at all.  We have been doing it for years.  (Hint: ./configure; make; 
>> make install)
>
> Yeah.
>
> I reiterate my point that I think it'd be good with a dedicated VM to build
> the snapshots and releases off, that isn't affected by other changes to
> whatever machine happens to be used. This VM could then be given all the
> required autoconf versions, and it'd stay stable - and wouldn't be affected
> by choices by whatever distribution is used.

That would work for flex and bison but we're (inexplicably afaict) *checking
in* the autoconf output into CVS. So it isn't the version of autoconf used to
cut the release which matters, it's the last version anyone used to run
autoconf.

I guess part of Marc's release cutting routine is to rerun autoconf and check
in that result? But that's arguably even worse. It means that after having
tested the source with whatever version of autoconf the last configure.in
hacker used for months we suddenly switch to whatever Marc's machine generates
just before release. Of course having every developer run autoconf suffers
from that problem too.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: offtopic, historic, in 8.1, how to find relfrozenxid by table?
Next
From: Gregory Stark
Date:
Subject: Re: [COMMITTERS] pgsql: update files for beta3