8.5 release timetable, again - Mailing list pgsql-hackers

I posted a note about a week ago which drew far less commentary than I
expected, regarding the timetable for the release of 8.5.

http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php

Perhaps this is already being discussed on -core, but if so the
conclusions haven't been shared publicly.  We started the first
CommitFest for 8.5 on July 15, 2009.  I believe that there is general
consensus on a two-month cycle for CommitFests, which means that the
second one will start on September 15, 2009, and the third one on
November 15, 2009.  The open question is whether there will be a
fourth or a fifth CommitFest, and what that will do to the time line
for the final release.

During the 8.4 development cycle, we started the last CommitFest on
November 1, 2008 and released 8 months later on July 1, 2009.  I would
like to think that we could shave a bit of time off of that this time
around, because last time the final CommitFest took approximately 4
months.  I found that to be pretty ridiculous and I think that I was
not the only one.  By the end, there were not too many patches left
and most of those had been thoroughly reviewed, so there was no
obvious role for non-committers to play.  There were also many patches
that went for weeks, sometimes over a month, without being updated or
bounced.  I think we can improve this a lot this time around, by
applying the same rules to the last CommitFest that we did to the
first one: patches must be updated in a timely fashion.  If they
can't, it's a sign that either the patch author is too busy to work on
the patch, or the revisions needed are too extensive for a single
CommitFest.  Either way, we move on.

I am a lot less clear on what we can do to shorten the time we spent
in beta.  In some ways, the time we spent in beta for 8.4 seems not to
have been long enough.  Several critical bugs introduced by the
infrastructure-changes-for-recovery patch were not fixed until just
before release, and a number of planner and other significant bugs
have been found since the release and will be fixed in 8.4.1.  On the
other hand, from my point of view, there was nothing to do during
beta.  Most of the open items required first and foremost a decision
about the best way to fix them, and those decisions really need to be
made by (or at least with the consent of) the committers.  If we have
a substantial open items list again for 8.5, we need to find a way to
formalize the handling of that list so that it can be dealt with
efficiently and the work distributed among as many people as are
willing and able to help.  Writing release notes also seemed to take a
lot of time, perhaps partly because we didn't know until the very end
whether certain large patches were going to be committed.

All of the above having been said, I think it's too much to hope that
the beta/release cycle is going to get drastically shorter than it was
for 8.4.  So I think if we decide on three CommitFests, the timetable
will end up going something like this:

2009-11-15 Last CommitFest Begins
2009-12-15 Last CommitFest Ends
2010-01-01 Alpha
2010-03-01 Beta
2010-05-01 Release

This schedule assumes that instead of having 8 months between
start-of-last-CommitFest and release, we'll have five and a half.
Assuming that we can avoid the temptation to let the last CommitFest
drag on and on and on, that seems achievable.

If we go with four CommitFests, we'll probably end up release 45-60
days later, in mid June or start of July.  If we go with five
CommitFests, we'll probably be looking at September.

Personally, I favor the more aggressive schedule of just three
CommitFests, because if something goes wrong and the schedule does
slip, we should still be able to get the release out the door next
year by the same time we did this year.  If things go as planned,
we'll have the release out the door in time for PGCon.  If things go
truly excellently and we manage to get the release out before 1-May,
then we have that much more time for 8.6 development.  On the other
hand, if we plan for four Commitfests, we'll be looking at releasing
the same time next year that we did this year *if* everything goes as
planned.  If anything slips, we'll release even later - and that also
gets into the summer time, when more people are away.

But, some other decision that has consensus is fine too. The most
important thing is to MAKE a decision before the passage of time makes
one for us.

...Robert