On Tue, Jun 30, 2009 at 12:37 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <j...@commandprompt.com> writes: >> On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote: >>> I would like to propose aiming for a release around April/May 2010 ... >>> "in time for PGCon" if you like, but the main point is to have it out >>> before people start disappearing for summer break. We've already run >>> into problems with scheduling the 8.4 release because of that. > >> I generally agree with this however why not just have a "When it is >> done?". Let's hit some commitfests and some time near the end of the >> year start discussing Beta and release. > >> We are not a company. We don't have a deadline. Why can't we just >> develop and say, "Yeah, this looks like it would make a substantive >> release."? > > Well, then you might as well not have a schedule at all. The point of > setting up a schedule is not to have a deadline that we must meet or > die trying (and certainly not to ship whether it's ready or not, as > a certain other OS database has been accused of doing). Rather, the > point of this exercise is to give individual developers a framework > to plan in. Without a target date it's tough to decide what is > reasonable to work on for 8.5.
I agree. On the other hand, I think all of the proposed schedules are somewhat optimistic about how long the final release will take. We started the final CommitFest for 8.4 on November 1st and are set to release July 1st. The proposed schedule for next time involves starting the final CommitFest three months later and releasing two months earlier. I'd like to think that with a little more discipline around CommitFests we can tighten things up a little, but it seems excessively optimistic to think that we're going to cut down from seven months to two. I would propose to start CommitFests July 15th, September 15th, November 15th, and January 15th, planning all but the last to be one month long. The last CommitFest I would plan on closing up by March 1st, with release hopefully by June 1st. As for thresholds, I'd propose that we measure the size of patches using "diff -u | diffstat". If the number of insertions plus the number of deletions is >= 1000, then the patch is not eligible for the final CommitFest unless it was submitted for the penultimate CommitFest. This obvious discriminates against patches with a large footprint that are not very invasive and in favor of those with a small footprint that are more destabilizing, but it's a clean line in the sand, and I think having such a line is better than trying to apply human judgment to every case. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
