Re: Last gasp - Mailing list pgsql-hackers

On Mon, Apr 9, 2012 at 7:38 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Apr 9, 2012 at 6:23 PM, Noah Misch <noah@leadboat.com> wrote:
>> But objective rules do not require a just judge, and they have a
>> different advantage: predictability.  If I know that a clock starts ticking
>> the moment I get my first review, I'll shape my personal plan accordingly.
>> That works even if I don't favor that timer to govern CFs.
>
> In theory this is true, but previous attempts at enforcing a
> time-based rule were, as I say, not a complete success.  Maybe we just
> need greater consensus around the rule, whatever it is.
>
> At any rate, I think your comments are driving at a good point, which
> is that 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.

We have seen a number of patches proposed where things have clearly
stepped backwards into the Design Phase, and when that happens, it
should be pretty self-evident that the would-be change can NOT
possibly be nearly-ready-to-commit.

It seems as though we need to have a "bad guy" that will say, "that
sure isn't ready to COMMIT, so we'd better step back from imagining
that it ought to be completed as part of this COMMITfest."

But there is also a flip side to that, namely that if we do so, there
ought to be some aspect to the process to help guide those items that
*aren't* particularly close to being committable.  That seems
nontrivial, as it shouldn't involve quite the same behaviors, and I'm
not quite certain what the differences ought to be.  Further, the
"HackFest" activities will be somewhat immiscible with CommitFest
activities, as they're of somewhat different kinds.

Or perhaps I'm wrong there.  Perhaps it's just that we need to be
*much* more willing to have the final 'fest bounce things.

I wonder if we're starting to have enough data to establish meaningful
statistics on feedback.  The "Scrum" development methodology tries to
attach estimated costs to tasks and then compare to completion rates
to then refine the estimates on completion rates to therefore improve
future estimates.  We have a fair body of data available from the
CommitFest data; perhaps it is time to try to infer some rules as to
what patterns on patches may indicate troubled features that are
particularly likely to get deferred.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"