Re: Last gasp

On Tue, Apr 10, 2012 at 3:26 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Christopher Browne <cbbrowne(at)gmail(dot)com> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>>> CommitFests are a time for patches that are done or very nearly
>>> done to get committed, and a time for other patches to get
>>> reviewed if they haven't been already.  If we make it clear that
>>> the purpose of the CommitFest is to assess whether the patch is
>>> committable, rather than to provide an open-ended window for it
>>> to become committable, we might do better.
>>
>> Yeah, I think there's pretty good room for a "+1" on that.
>
> Yeah, +1 for sure.

The top comment that has been +1'd presents just 2 states; 1 is
deliberately phrased to be ridiculous, so of course everybody will
vote for the other one.

What is missing there is all of the other possible states between
those two extremes.

Let me re-phrase that: I think open ended CFs aren't much use. Hard
edges are needed. But having said that, I can't think of a major
feature that didn't have some tweaking after commit, and after end of
CF.

> One other sort of mechanical test which I think can and should be
> applied to patches submitted to the last CF is that if *at the start
> of the CF* the patch doesn't apply, compile, pass regression tests,
> and demonstrably provide the functionality claimed for the patch, it
> should not be a candidate for inclusion in the release.  A patch on
> which the author is continuing to work even in the absence of review
> should be considered a WIP "want feedback" submission; it should not
> be allowed to constitute a "placeholder" for inclusion in the
> release.  It's one thing if review turns up corner case bugs missed
> by the author; it's quite another if there is a month or two of
> solid development left to be done. The CF period is not the time for
> "now I'll get serious about wrapping this up."

Agreed. But again, mistakes do happen, so reasonableness is required.

CommitFests should be a finalisation period where submissions get
tweaked to fix problems/bugs and allow them to be committed by the end
of the CF. Again, in some cases that might be on the last day of the
CF (else its not the last day...).

In the past, patches could "starve" on the queue for very long
periods, sometimes years. Having a too-harsh process makes it then
easy to go back to the old way of quickly bouncing things that lack
popularity from committers.

Anyway, this discussion is just the annual "make things better"
discussion. Our process was good to start with and has get better each
release for years and years now, so objectively we are doing quite
well.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services