Re: branching for 9.2devel

All,

> �I'm not aware that we've set
>>> any dates for 9.2 CommitFests yet ...

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.

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.

=============

Re: shorter CF cycle: this works based on the idea of a "one strike" for
each patch. That has the benefit of pushing more of the fixing work
onto the authors and having less of it on the committers: "Not ready,
fix X,Y,Z and resubmit."

I think that doing thing that way might actually work. However, it will
require us to change the CF process in several ways. I'll also point
out that pushing fixing work back on the authors is something which
committers could be doing *already* in the present structure. And that
there's no requirement that our present CFs need to last for a month.

The main issues with a "monthly commit week" are:

1) Triage: it's hard to go from first-time reviewer --> review -->
committer in a week, so a lot of patches would get booted the next CF
just due to time, and

2) availability: some patches can only be understood by certain
committers, who are more likely to be gone for a week than a month, and

3) The CF tool, which is currently fairly manual when it comes to
pushing a patch from one CF to the other. This is the easiest thing to fix.

However, given all that, there would be some serious advantages to a
monthly commit week:

a) faster feedback to submitters, and

b) more chances for a developer to fix their feature and try again, and

c) more of an emphasis on having the submitter fix what's wrong based on
advice, which
* conserves scarce committer time, and
* helps the submitters learn more and become better coders

d) eliminates the annoying dead time in each CF, where for the last week
of the CF only 2 extremely difficult patches are under review, and

e) eliminates the stigma/trauma of having your stuff rejected because
everyone's stuff will be rejected at least once before acceptance, and

f) even allows us to punt on "everything must be reviewed" if nothing
gets punted more than once.

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

It may not work. I think it's worth trying though, and we can always
revert to the present system if the 1-week CFs are impeding development
or are accumulating a snowball of patch backlog.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com