On Wed, Sep 2, 2009 at 7:42 PM, Josh Berkus<j...@agliodbs.com> wrote: > Hackers, > > Per discussions on two other threads on this list which have apparently > reached consensus, we will be going with the following schedule: > > CF1 7/15 to 8/14 > Alpha1 by 8/20 > CF2 9/15 to 10/14 > Alpha2 by 10/20 > CF3 11/15 to 12/14 > Alpha3 by 11/20 > CF4 1/15 to 2/14 > Alpha4 by 2/20 > Beta1 est. 3/1 to 3/7 > Release June, depending on bugs > > The corollary to the above is that CF4 will end on Valentine's Day even > if we have to reject patches to do it.
I would like to propose an additional stipulation on CF4 - namely, that we will reject out of hand any large patches that were not submitted to CF3. For the sake of definiteness, let's say that a large patch is anything whether diffstat run against the unified diff shows lines added + lines removed >= 1000. I think this is important both for making sure that CF4 ends on time and also for making sure that we don't destabilize the tree too much late in the development cycle. Going further with that theme, I think that we should further agree that if, in the judgement of the relevant reviewers/committers, any given patch submitted for CF4 seems as though it may destabilize the tree in a way that will significantly prolong beta, or if the patch as submitted seems likely to need follow-on patches before the feature is release-worthy, we will punt it to 8.6. Obviously, these will be judgement calls, but I think it will be easier to make them if we state the ground rules and expectations up front. I'd also like to add that the decision should be made based on *having read the patch* rather than any theory about the relative value of the feature. We seem to have consensus on a time-based release, so let's try to release on time. I'd also like to propose that we schedule an open-items-fest for 3/15-4/14. My vision is that we'll try to make sure that we have a complete list of open items, including any that are lurking in the mailboxes of Tom, Bruce, or others, by 3/15. We'll ask for volunteers to address those open items. Then on 3/15 we'll dole them out and ask each person to come up with a proposed plan of action for the open item assigned to them and post it to -hackers. In some cases, closing the item may mean writing a patch, which we'll ask the volunteers to help with when possible (but sometimes it won't be), but at a minimum, the volunteers need to make sure that consensus on how to handle the item is reached, so that when someone who has the necessary coding-fu has time to put into it, they know what code they're supposed to be writing. Thoughts? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
