Josh Berkus <j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
