Re: branching for 9.2devel - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: branching for 9.2devel |
Date | |
Msg-id | 15233.1303747426@sss.pgh.pa.us Whole thread Raw |
In response to | Re: branching for 9.2devel (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: branching for 9.2devel
Re: branching for 9.2devel |
List | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane <tgl@sss.pgh.pa.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
pgsql-hackers by date: