Re: branching for 9.2devel - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: branching for 9.2devel
Date
Msg-id 4DBD4E98020000250003D0BB@gw.wicourts.gov
Whole thread Raw
In response to Re: branching for 9.2devel  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: branching for 9.2devel  (Robert Treat <rob@xzilla.net>)
List pgsql-hackers
Robert Treat <rob@xzilla.net> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>        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
>>
>> I think the main thing we have to think about before choosing is
>> whether we believe that we can shorten the CFs at all.  Josh's
>> proposal had 3-week CFs after the first one, which makes it a lot
>> easier to have a fest in November or December, but only if you
>> really can end it on time.
> 
> If we made the "deadline" for patch acceptance into 9.2 CF#4, then
> shortening that to a two week cycle whose main goal was simply to
> sanity check patches for 9.2 would probably work. Most would
> probably still need further work, which we would expect to get
> handled in the final, full CF#5, but we wouldn't let anything new
> come into CF#5. This way when we get the 100 patch pile up in
> CF#4, there's no expectation that those patches will be committed,
> just that they can be sanity checked for the 9.2 release.
Which makes it not really a CommitFest, but rather ... a SanityFest?
To make sure I understand you, you're suggesting no WIP patch review
in the last two CFs?  (Of course nothing stops someone from looking
at someone else's WIP between fests.)  Would a patch submitted to
#4, the sanity of which was questioned, be eligible for another try
in #5.
I'm just trying to picture how this idea might work.
-Kevin


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: a bit strange btree index tuples
Next
From: Robert Treat
Date:
Subject: Re: branching for 9.2devel