Re: Formatting Curmudgeons WAS: MMAP Buffers - Mailing list pgsql-hackers

On Wed, Apr 20, 2011 at 3:42 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 4/20/11 12:35 PM, Tom Lane wrote:
>> Well, no, that's not the whole story.  To me, what the above idea
>> implies is shifting more of the burden of fixing up patches away from
>> the committer and back to the patch author.  Instead of spending time
>> fixing up not-quite-ready patches myself, I'd be much more ready to
>> tell the patch author "do X, Y, and Z, and come back next month".
>
> Yes, definitely!  For that matter, booting a patch which got no review
> is less of a problem if we're only booting it for 3 weeks.
>
> The whole purpose of the CFs was not to help submitters -- it was to
> help reviewers.   If we just wanted to help submitters, we'd do
> Continuous Integration, and review all the time.  But the reviewers need
> "time off".
>
> I think we should try this for 9.2.  Given the accumulation between then
> and now, I think the first CF should be 2 weeks, and then we can move to
> monthly/weeklong CFs after that.  So it would look like:
>
> CF1: July 16-31
> CF2: August 1-7
> CF3: September 1-7
> CF4: October 1-7
> CF5: November 1-7
> CF6: December 1-7
> CF7: January 3-10
> CF8: February until done

I am concerned that this will get us back into the land of the
interminable last CommitFest.  I believe that one of the reasons why
things didn't go as smoothly before we had the CommitFest was because
patches didn't get dealt with until the end of the cycle.  I think
that if, as proposed, we are faster about pushing patches back on the
submitters when they're not up to snuff, then we will end up having
more stuff bounce along for many CommitFests without actually getting
committed, which will tend to exacerbate the pile-up at the end of the
cycle.  The basic underlying problem here is that there is tremendous
reluctance to boot anything when it means pushing it out to the next
release, and I think that's just terrible project management.  If we
had punted collations and sync rep to 9.2, we would be on beta2 right
now, instead of still trying to get things squared away for beta1.  If
we allow people to submit patches up until supposed feature freeze - 7
days instead of proposed feature freeze - 31 days, that's not going to
help.

Now, maybe if we branched the tree immediately after the last CF of
the release and continued having week-long CFs, we might be able to
make it work.  Then, at least if you didn't get your stuff committed
to the right release, you could still get it committed somewhere.  But
even then I think we'd have this problem of people being unwilling to
give up on jamming stuff into a release, regardless of the scheduling
impact of doing so.  I actually think the problem of getting releases
out on time is a *much* bigger problem for us than how long or short
CommitFests are.

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