Re: branching for 9.2devel

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: branching for 9.2devel
Date: 2011-04-25 19:00:08
Message-ID: 18502.1303758008@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-04-25 19:05:29 Re: Unlogged tables, persistent kind
Previous Message Peter Eisentraut 2011-04-25 18:50:28 Re: Unfriendly handling of pg_hba SSL options with SSL off