Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> 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.
I just don't see any great value in it. I keep trees for doing commit
work on all branches on my workstation - I suspect most other committers
do too. I'm going to want the relevant configure version where I do my
work, so I can test things out. Having multiple versions around isn't a
huge burden.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
