On Sun, Aug 23, 2009 at 1:57 AM, Tom Lane<t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> 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. > > Core hasn't discussed 8.5 schedule since the discussions that Peter > summarized in the message you cited above. I share your concern that > "release in time for PGCon" isn't very realistic if we don't get more > aggressive about schedule. On the other hand, we didn't get all that > much done in this fest. If we cut back to a three-fest schedule > I think we may succeed in releasing 8.5 early, but only because there > is nothing interesting in it :-(. Dunno where the right balance is.
Here is my thinking on that point. We have several major features underway for the September CommitFest, including at least Hot Standby (Simon Riggs), Streaming Replication (Fujii Masao), and Index-Only Scans (Heikki). At the July CommitFest, none of these patches were in a state where they could be seriously reviewed. Simon Riggs and Fujii Masao have both committed to produce reviewable versions by 9/15, and it looks like Heikki will hit that date too, if not beat it. I am assuming that at least Hot Standby and Streaming Replication will likely require two CommitFests to go from the point where they are seriously reviewable to actual commit. So if they hit the 9/15 date, they should make 8.5 even with just three CommitFests. If they don't hit the 9/15 date, then a 3-CommitFest cycle will probably be too short for them to make it in. But if we schedule a fourth CommitFest in January in the hopes of seeing one of those patches committed, then ISTM we're basically speculating that the patch authors will not hit the 9/15 date but that they will hit an 11/15 date. To me, that's an entirely arbitrary and unfounded speculation. On the one hand, both patch authors have said they will hit 9/15, so why should we second-guess them? On the other hand, neither of those patches seems to have made a great deal of progress in the last 7 months, so it's unclear that tacking a few more months onto the schedule will help anything. Furthermore, even if we're right that four CommitFests is the right number to land one of those patches (rather than 3 or 5 or 6 or 7), we're then talking about committing a major feature in the very last CommitFest for this release. We tried that for 8.4 and it wasn't a stunning success. To some degree, what this boils down to is that you can have time-based releases or feature-based releases, but not both. And the problem with feature-based releases in a community environment is that there is no guarantee that patches will be delivered when promised. None of the people developing these major features work for the community and we do not have the ability to control any of their schedules. So saying that we're going to wait for them to be ready is potentially saying that we're going to wait forever. No one is proposing that, but we are sort of trying to read the tea leaves and try to guess when they might be ready and tailor the schedule to it. To me, it seems to make more sense to just decide we're going to ship the release on a time line that works for the project overall. If we get some new features in, good. If they slip a bit past the deadline, well, at least that should hopefully mean that they get committed right at the beginning of the 8.6 cycle. If they slip WAY past the deadline, bummer, but at least we didn't hold up the release to no benefit. I don't think there's anything wrong with having a release that has many small improvements but no major new features, and I think that is the worst that will happen. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
