Re: [HACKERS] CVS Branch Tagging...

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: [HACKERS] CVS Branch Tagging...
Дата
Msg-id Pine.BSF.4.05.9810220832090.3048-100000@thelab.hub.org
обсуждение исходный текст
Ответ на Re: [HACKERS] CVS Branch Tagging...  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
Ответы Re: [HACKERS] CVS Branch Tagging...
Список pgsql-hackers
On Thu, 22 Oct 1998, Thomas G. Lockhart wrote:

> > While it will be possible, I would like people to concentrate on the
> > existing 6.4 issues we have, and discourage parallel development on
> > separate final and features source trees.
> 
> As Bruce describes, a "quiet time" just before and up to a month after a
> major release is a _really_ good idea. For a couple of reasons:
> 
> 1) it lets us put out bugfix releases with a minimum of trouble
> 
> 2) it lets people planning larger changes for the next release to work
> on a stable, quiet tree, with some assurance that they will likely be
> able to remerge their work when things unfreeze.
I don't agree...the problem is that our times between releases
tends to be...erratic.  It was supposed to be 3+1mos, and is turning into,
what, 5+1? 
Not all changes to the source tree require a dump/reload to take
effect...we have 4 patches in the ftp site right now, to v6.3.2, with the
first dated Apr21st, and the last dated Jul30th.  With a STABLE vs CURRENT
branch, those patches could have been applied to the STABLE branch, and a
quick v6.3.x release could have been regress tested and released.  That in
itself would have saved some of the problems where ppl had downloaded the
'newest release' but had problems because they didn't grab the patches to
go along with it.
The problem right now is we look at it as being one stream...right
now, the only thing that should be left for v6.4 is bug fixes, and there
should be no reason to hold up continued development while we wait for
each possible bug report to flow in.
With two branches, there should be no reason why a patch that
Vadim comes up with to fix a "rarely hit, but often disastrous" bug in
indexes can't be applied and tested in both tree.  Then a quick v6.4.1 can
be released that those not wishing to run "latest and greatest" can run
without having to lose out on that major fix...
The idea is that with very little work on anyone's part, we can
easily provide a more stable foundation for those starting out and wishing
to use it in a production environment.  Right now, we have a v6.3.2 from
April 19th, with four patches that can be applied...but how many ppl would
actually apply those patches in a production environment?  Most ppl would
download and upgrade to v6.3.3 which had those patches applied...
I don't know...its something we just did with INN, cause we still
had some bugs to work out on 2.2, but some of the developers who don't
work on the areas involved are getting restless to get some work
done...gives them a chance to move forward without affecting the RELEASE
scheduale...

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



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

Предыдущее
От: "Philippe Rochat (RSR: 318 17 93)"
Дата:
Сообщение: Time format ? (Really microsecond ??)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] psql's help