Magnus Hagander wrote:
> 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.
>
>
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
