Re: branching for 9.2devel - Mailing list pgsql-hackers

From Tom Lane
Subject Re: branching for 9.2devel
Date
Msg-id 18502.1303758008@sss.pgh.pa.us
Whole thread Raw
In response to Re: branching for 9.2devel  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> As much as I'd like to start development early officially, I'm with Tom
> in being pessimistic about the bugs we're going to find in SSI,
> Collations and Synch Rep.  Frankly, if you and Tom weren't so focused on
> fixing it, I'd be suggesting that we pull Collations from 9.1; there
> seems to be a *lot* of untested issues there still.

If I had realized two months ago what poor shape the collations patch
was in, I would have argued to pull it.  But the work is done now;
there's no reason not to keep it in.  The cost is that I wasn't paying
any attention to these other areas for those two months, and we can't
get that back by pulling the feature.

> I do think that we could bump the first CF up to July 1st, but I don't
> think sooner than that is realistic without harming beta testing ... and
> potentially delaying the release.  Let's first demonstrate a track
> record in getting a final release out consistently by July, and if that
> works, maybe we can bump up the date.

The start-date-on-the-15th was an oddity anyway, and it cannot work well
in November or December.  +1 for putting the CFs back to starting on the
1st.

> Overall, I think the advantages to a faster/shorter CF cycle outweigh
> the disadvantages enough to make it at least worth trying.  I'm willing
> to run the first 1-week CF, as well as several of the others during the
> 9.2 cycle to try and make it work.

I think we could try this once or twice without committing to doing the
whole 9.2 cycle that way.

> I also have an idea for dealing with Problem 1: we actually have 2
> weeks, a "triage week" and a "commitfest week".   During the Triage
> week, non-committer volunteers will go through the pending patches and
> flag stuff which is obviously either broken or ready.  That way, by the
> time committers actually need to review stuff during CF week, the easy
> patches will have already been eliminated.  Not only will this
> streamline processing of the patches, it'll help us train new reviewers
> by giving them a crack at the easy reviews before Tom/Robert/Heikki look
> at them.

We've sort of unofficially done that already, in that lately it seems
the committers don't pay much attention to a new fest until several days
in, when things start to reach "ready for committer" state.  That
behavior would definitely not work very well in 1-week CFs, so I agree
that some kind of multi-stage design would be needed.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: branching for 9.2devel
Next
From: Peter Eisentraut
Date:
Subject: Re: "stored procedures"