Re: Last gasp - Mailing list pgsql-hackers

On Sat, Apr 7, 2012 at 5:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wonder whether we ought to have a preset schedule for last fests
> just like the others.

It's always been my feeling that we should have that.

> There's too much temptation to commit
> patches that are not really ready, just to get them out of the way.

This is something I'm really concerned about.  During both the 9.0 and
9.1 cycle, we did some of this, and ended up paying for it with months
of bug fixing - not of *everything* that was committed late in the
cycle, but of certain particular patches.  We ended up producing
quality releases anyway, but I think if we had pushed it much farther
than we did, that might not have happened, or it might have pushed the
release out quite a bit more.  I think we have to be careful not to
set the bar for big patches unreasonably high (or big features will
never get done) but I honestly do not believe we have that problem.
Which recent release did not end up with its share of big features?
People like Jeff Davis, KaiGai Kohei, and myself who submitted their
major work (or the preparatory refactorings) relatively early in this
release cycle had no real trouble getting commits.  It is the patches
that showed up in November, December, and January that ended up on the
skids.  On the flip side, we do have a problem with looming deadlines
causing a lot of pressure to push stuff in that isn't ready.  There
were a number of times this CommitFest when someone said, hey, I'm
going to push X, and I said... uh, let me drop what I'm doing and take
a look at that, because it doesn't sound ready to me.  Some of those
commits happened anyway and others didn't, but all of them seemed like
the outgrowth of time pressure rather than real certainty that we were
in a good place.

> 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.

Well, the other side of the coin is that the next release will
probably be in a little over a year, and that's longer than people
want to wait even if it's a known quantity.  But I'm not sure there's
much we can do about that, unless we want to cut the cycle from four
CommitFests to three, or something like that.  I think I'd actually be
in favor of that, because it seems to me that nearly every feature
anyone wants can be gotten done in two CommitFests.  There are a few
exceptions, like sepgsql and SSI and (now) command triggers, but it's
not like we have tons of developers who start in CF1 and just barely
get their work in by CF4.  What happens more often is that the early
CommitFests are kind of dead, and then there's a huge flood of stuff
for the last one because, hey, there's gonna be a release soon, I
should do something for it!  We might find that if we did 3-CF cycles
rather than 4-CF cycles we got the same number of features about two
months sooner.

Or we might not find that.  But it's not clear that cutting off a
CommitFest would have hurt this release much, or that adding another
one would have helped much.  Adding one *now* might help, because some
of the big patches that were submitted at the beginning might then
make it in, but if we'd had all of this extra time budgeted in from
the beginning (e.g. last CommitFest planned for March 1st instead of
January 15th) I think a decent number of the submissions would have
just come that much later.  Love may be the strongest human emotion,
but procrastination has got to be in the top five.

The only thing I can really see helping us to avoid the crush of last
minute patches is to have strong, clear, and vigorously enforced rules
about rejecting major features that are not submitted early enough, or
that are not in good enough shape when submitted.  As you said in your
reply to Peter, making exceptions because features are "important" is
not helpful.  My features are important, too, but I get them done
early.  Granted, not everyone has as much work time to work on
community PostgreSQL as I do, but it's simply impossible to believe
that everyone's schedule suddenly clears up in the first half of
January every year.  If there's something magic about that half-month
then we've chosen a poor timing for our final CommitFest, but my
theory is that we'd have the same problem no matter when we did it.
If we start aggressively booting things early, then we don't have to
have arguments at the end.  But then again, we'd have to have the
arguments earlier.  I continue to think that there's no real solution
here if people are bound on claiming that the feature they
particularly like ought to be excepted from the deadlines that apply
to everyone else.

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