Re: branching for 9.2devel

On Mon, Apr 25, 2011 at 12:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> You're ignoring the extremely real costs involved in an early branch,
> namely having to double-patch every bug fix we make during beta.
> (And no, my experiences with git cherry-pick are not so pleasant as
> to make me feel that that's a non-problem.)  I really don't think that
> we should branch until we're willing to start doing 9.2 development in
> earnest.  You're essentially saying that we should encourage committers
> to do some cowboy committing of whatever 9.2 stuff seems ready, and
> never mind the distributed costs that imposes on the rest of the
> project.  I don't buy that.
>
> IOW, the decision process ought to be set 9.2 schedule -> set CF dates
> -> set branch date.  You're attacking it from the wrong end.
>
>> I'm inclined to suggest that we just go ahead and schedule five
>> CommitFests, using the same schedule we have used for the last couple
>> of releases, but with one more inserted at the front end:
>
>> May 15, 2011 - June 14, 2011
>> July 15, 2011 - August 14, 2011
>> September 15, 2011 - October 14, 2011
>> November 15, 2011 - December 14, 2011
>> January 15, 2012 - February 14, 2012
>
> Well, if you go with that, then I will personally refuse to have
> anything to do with the first CF, because I was intending to spend
> my non-bug-fix time during beta on reading the already committed but
> probably still pretty buggy stuff from 9.1 (SSI and SR in particular).
> I think a schedule like the above will guarantee that no beta testing
> gets done by the development community at all, which will be great for
> moving 9.2 along and terrible for the release quality of 9.1.
>
> I think the earliest we could start a CF without blowing off the beta
> process entirely is June.  Maybe we could start CFs June 1, August 1,
> etc?

I can't object to taking another two weeks, especially since that
would give people who may have been expecting a later branch more time
to get their stuff into shape for CF1.

One problem with that is that it would make the fourth CommitFest
start on December 1st, which will tend to make that CommitFest pretty
half-baked, due to the large number of PostgreSQL developers who
observe Christmas. That seems particularly bad if we're planning to
end the cycle at that point. Perhaps that would be a good time to
employ Peter's idea for a short, one week CommitFest:

CF #1: June 1-30
CF #2: August 1-31
CF #3: October 1-31
CF #4 (one week shortened CF): December 1-7
CF #5: January 1-31

That would give people another crack at getting feedback before the
final push, right at the time of the release cycle when timely
feedback becomes most important.

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