Re: Last gasp - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Last gasp
Date
Msg-id 8687.1333833601@sss.pgh.pa.us
Whole thread Raw
In response to Re: Last gasp  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Last gasp  (Thom Brown <thom@linux.com>)
Re: Last gasp  (Peter Geoghegan <peter@2ndquadrant.com>)
Re: Last gasp  (Robert Haas <robertmhaas@gmail.com>)
Re: Last gasp  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> [ among other good points ]
> ... On a related note, letting CommitFests go on for three
> months because there's insufficient reviewer activity to get them done
> in one or two is, in my opinion, not much of a solution.  If there's
> even less reviewer activity next time, are we going to let it go on
> for four months?  Six months?  Twelve months?  At some point, it boils
> down to "we're just going to stop accepting patches for an indefinite
> period of time".  Yuck.

Yeah, this is something I was thinking about yesterday.  In the first
couple of release cycles with the CommitFest process, we were willing to
let the last fest of a release cycle go on for "as long as it takes",
or at least that was what I felt the policy to be.  This time we
eventually gave up and declared closure, but in hindsight we should
likely have done that a month earlier.  The fact of the matter is that
quite a few of the patches we were dealing with were *not* ready to
commit, or even close to that, at the start of the fest.  If it weren't
the last fest they would have gotten marked Returned With Feedback a
lot sooner.

I wonder whether we ought to have a preset schedule for last fests
just like the others.  I'd be willing to let them run, say, 2 months
instead of 1, but no deadline at all risks turning the whole affair
into a death march, which is no fun for anybody and threatens the
quality of the end result too.  There's too much temptation to commit
patches that are not really ready, just to get them out of the way.

In short, the idea of strongly calendar-driven releases looks more
and more attractive to me the more times we go through this process.
If your patch isn't ready on date X, then it's not getting into this
release; but there'll be another bus coming along before long.
Stretching out release cycles to get in those last few neat features
just increases the pressure for more of the same, because people don't
know how long it will be to the next release.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Last gasp
Next
From: Thom Brown
Date:
Subject: Re: Last gasp