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
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 |