Re: [COMMITTERS] pgsql: update files for beta3

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [COMMITTERS] pgsql: update files for beta3
Дата
Msg-id 473DC2D9.6070704@hagander.net
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: update files for beta3  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: update files for beta3
Следующее
От: Sam Mason
Дата:
Сообщение: Re: Javascript support in the backend, i.e. PL/JS