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

From Magnus Hagander
Subject Re: [COMMITTERS] pgsql: update files for beta3
Date
Msg-id 473DC2D9.6070704@hagander.net
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: update files for beta3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: update files for beta3  (Andrew Dunstan <andrew@dunslane.net>)
Re: [COMMITTERS] pgsql: update files for beta3  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> 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's really not the worst part of the problem.  The worst part is that
> all developers who ever touch the configure script need to have the same
> autoconf version installed, and when dealing with back branches need to
> remember to use the right version.  So I think focusing on only the
> environment used for tarball-building misses the point.  We need a
> solution targeted at all-developers-including-Marc, not one that just
> sets the release process in stone.

So let's create a VM for just this? A VM is very cheap, it just costs a
bit of disk space as long as it's not used. And give committers access
to it, to use it for committing these changes (unless they are running
the correct version at home - a simple cvs diff before committing should
show you very clearly if you're not).

And before it's suggested, this should not be the cvs VM. The cvs VM is
a dedicated VM for just that for stability and security reasons. It
should remain that. Even though it's a VM where all the devs have
accounts already.

> One idea people might suggest is to stop keeping the generated configure
> script in CVS.  I'm not sure that'd make things better though.  We'd be
> buying into the concept of trying to make configure.in work with any
> autoconf version any developer might be likely to use.  I'm really not
> too sure what the functional incompatibilities between versions are,
> but given the extent of line-by-line diffs I've seen in the output of
> even adjacent versions, this isn't a question I want to take lightly.

Having it in cvs made life a *lot* easier when developing with mingw.
Getting the proper autoconfy stuff going there is not easy at all. I'm
sure there can be others having the same problems.

I would much prefer a solution that keeps it in cvs.

//Magnus



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: update files for beta3
Next
From: Sam Mason
Date:
Subject: Re: Javascript support in the backend, i.e. PL/JS