Re: branching for 9.2devel

On Mon, Apr 25, 2011 at 2:26 PM, Josh Berkus <josh@agliodbs.com> wrote:
> I thought the idea of setting the initial CF for July 15th for 9.1 was
> that we would consistently have the first CF in July every year?  As
> discussed at that time, there's value to our corporate-sponsored
> developers in knowing a regular annual cycle.

Huh?  We've never guaranteed anyone a regular annual cycle, and we've
never had one.  We agreed to use the same schedule for 9.1 as for 9.0;
I don't remember anything more than that being discussed anywhere,
ever.

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

I have no idea where you're coming up with this estimate.

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

This is basically admitting on its face that one week isn't long
enough.  One week of triage and one week of CommitFest is two weeks,
and right there we've lost all of the supposed benefit of reducing the
percentage of time we spend "in CommitFest mode".  Furthermore, it's
imposing a rigid separation between triage and commit that seems to me
to have no value.  If a patch is ready to commit after 3 days, should
we ignore it for 4 days and then go back and look at it?  Or should we
maybe just commit it while the thread is still fresh in someone's mind
and move on?  The current process allows for that and, well, it
doesn't work perfectly, but defining more rigid process around the
existing process does not seem likely to help.

At the risk of getting a bit cranky, you haven't participated in a
material way in any CommitFest we've had in well over a year.  AFAICS,
the first, last, and only time you are listed in the CommitFest
application is as co-reviewer of a patch in July 2009, which means
that the last time you really had a major roll in this process was
during the 8.4 cycle.  So I'm really rather suspicious that you know
what's wrong with the process and how to fix it better than the people
who are involved currently.  I think we need here is more input from
the people who are regularly submitting and reviewing patches, and
those who have tried recently but been turned off by some aspect of
the process.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company