Re: Release planning (was: Re: Status report)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Release planning (was: Re: Status report)
Дата
Msg-id 19845.1089759236@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Release planning (was: Re: Status report)  ("Marc G. Fournier" <scrappy@postgresql.org>)
Ответы Re: Release planning (was: Re: Status report)
Список pgsql-hackers
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Tue, 13 Jul 2004, Lamar Owen wrote:
>> But Tom's assertion is true.  We have enough trouble getting patches 
>> rolled out; adding parallel branches is just begging for trouble, due to 
>> our relatively small resource size.  Although, we probably have enough 
>> developers at this point to make it happen.

> Except, we already have parallel branches, else we'd never have made a 
> 7.4.x release ...

The point though is that we expend only very minimal effort on
maintaining the stable branches.  We only back-patch bug fixes, and 99%
of the time the patch is nearly verbatim the same change as we developed
to fix the same problem in HEAD.  If the code involved has changed
enough that a significantly different fix would be required, most of the
time we simply don't fix the stable branch.  And we spend very nearly
zero effort on QA for the stable branch --- there's certainly no
significant push to get people to beta-test minor releases.

If we did anything much in the way of back-porting features then the
level of investment in this would have to rise greatly.  In fact, if the
proposal is to let people pick and choose which back-ported things they
install, then we are not talking about just one stable version but 2^N
stable versions for N options.  We couldn't possibly test every
combination.

>> The BSD's release something like that, with CURRENT, TESTING, and STABLE,
>> right? (I'm not a big BSD user...)

Yeah, but they don't support mix-and-match feature sets.  A back release
has only one current version.

We could certainly do something along that line if we had a few people
willing to be "gatekeepers".  We'd have to work harder at making the
release generation process open and documented though.  Right now there
are plenty of steps that only you, Bruce, or Lamar (respectively) know
how to do...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Point in Time Recovery
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Proposal for detecting encoding mismatch in initdb