Re: Schedule for 8.5 Development

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

In response to

Responses

Browse pgsql-hackers by date

  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