Skip site navigation (1) Skip section navigation (2)

Re: 8.5 release timetable, again

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.5 release timetable, again
Date: 2009-08-31 01:09:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Aug 29, 2009 at 1:05 PM, Bruce Momjian<bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> Both committers and non-committers are currently suffering from the
>> fact that there is not a lot of time in the year which is set aside
>> for development, i.e. neither CommitFest-time nor beta-time.  To fix
>> this problem, we can:
>> 1. Make CommitFests shorter.
>> 2. Make CommitFests less frequent.
>> 3. Continue developing during CommitFests.
>> 4. Make beta cycles shorter.
>> 5. Make beta cycles less frequent (i.e. lengthen the release cycle).
>> 6. Continue developing during beta.
>> I believe (1) to be completely impractical and (3) to be
>> self-defeating.  I suspect (2) will backfire badly.  That doesn't
>> leave us with a lot of options.  We can certainly do (5), but the
>> downside is that features that get committed won't hit release for a
>> very long time.  I and others have suggested a couple of possible
>> approaches toward (4) or (6), such as changing the way we do release
>> notes, adding more regression tests to give us more (not perfect)
>> confidence that the release is solid, and/or branching the tree during
>> beta.  None of those ideas have gotten a single vote of confidence
>> from you or Bruce.  What's your suggestion?
> Another solution would be to make major releases less frequent.

I mentioned that one.  It's #5.  I also mentioned the downside.
Downthread you make reference to PostgreSQL being feature-complete,
but I don't personally think that's the right way to think about it.
The people who are submitting patches are doing so because they feel
that the product is missing the features implemented by those patches.
 Sure, some patches are pure performance plays, or bug fixes, or
documentation improvements, but many of them are new features, plain
and simple.  And the people who submit those patches want to see them
in a released version on a reasonable time scale.  I do, anyway.

I really can't understand why it isn't possible for us to find a way
to make an annual release happen, and with more than 8-12 weeks of
development time (ie non-CommitFest non-beta) available during that
year.  I understand that there is a need for some time to be set aside
for reviewing, testing, debugging, packaging, and so forth, but the
current schedule contemplates that this time is upwards of 75%, and I
think that's excessive.


In response to


pgsql-hackers by date

Next:From: Andrew McNamaraDate: 2009-08-31 02:42:12
Subject: Re: Upcoming minor releases
Previous:From: Bruce MomjianDate: 2009-08-31 00:22:51
Subject: Re: 8.5 release timetable, again

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group