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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
