Re: branching for 9.2devel

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: branching for 9.2devel
Date: 2011-04-25 16:03:46
Message-ID: 15233.1303747426@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> But a much more significant issue is that I don't see a lot of point in
>> branching until we are actually ready to start active 9.2 development.
>> So unless you see this as a vehicle whereby committers get to start
>> hacking 9.2 but nobody else does, there's no point in cutting a branch
>> until shortly before a CommitFest opens. I'm not aware that we've set
>> any dates for 9.2 CommitFests yet ...

> That doesn't strike me as a condition prerequisite for opening the
> tree. If anything, I'd say we ought to decide first when we'll be
> open for development (current question) and then schedule CommitFests
> around that. And I do think there is some value in having the tree
> open even if we haven't gotten the schedule quite hammered out yet,
> because even if we don't have any formal process in place to be
> working through the 9.2 queue, some people might choose to work on it
> anyway.

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-04-25 16:04:52 Re: Patch for pg_upgrade to turn off autovacuum
Previous Message David E. Wheeler 2011-04-25 16:00:26 Re: Extension Packaging