From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Schedule for 8.5 Development |
Date: | 2009-09-03 01:08:17 |
Message-ID: | 603c8f070909021808l1e6f769dkde29e3936a323572@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 2, 2009 at 7:42 PM, Josh Berkus<josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-03 01:30:41 | Re: initdb: The password file was not generated. |
Previous Message | Greg Stark | 2009-09-03 00:37:16 | Re: remove flatfiles.c |