Re: Last gasp

On 04/07/2012 04:51 PM, Robert Haas wrote:
> 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?

There should be a feedback loop here, one that makes it increasingly
obvious to people writing features that such work will screech to a halt
unless it's paired with review work. An extreme enforcement might be a
bias toward outright rejecting things from people we haven't seen a
review from before. That sort of message is hard to deliver without
discouraging new developers though, even though I think there's a lot of
data to support such a thing. You learn a lot about how to harden a
submission against the things any reviewer is likely to do by doing a
review yourself.

That said, it seems to me that the large patches are the ones that clog
the review system the most, and those are usually coming from known
contributors. Unfortunately, even if you know the situation here,
making it clear to sponsors that review is just as important as new
development is a hard sell sometimes. There's a sales pitch needed
there, one that makes it clear to people that the review workflow is
actually an essential part of why the PostgreSQL code is high quality.
Going through review isn't overhead, it's a key part of the process for
the benefit of the feature.

> I think that there are many projects that are more open to "just
> committing things" than we are - perhaps no better exemplified than by
> Tom's recent experiences with Henry Spencer's regular expression
> engine and the Tcl project. If you're willing to do work, we'll
> assume it's good; if you know something and are willing to do work,
> here are the keys. We could decide to take that approach, and just
> generally lower our standards for commit across the board.

This is a bit of a strawman argument as you constructed it. There's a
large middle ground between the current CF process and "just committing
things". One problem here is that there just isn't enough unique people
committing things, and adjusting the commit standards may be necessary
to improve that.

Right now I think there's a systemic structural problem to how people
and companies approach the development cycle for each release. Getting
things into the last CF just before a release has a better rate of
return on the work, making it easier for people to justify spending time
on. There's less elapsed time before you will see the results of your
work in production.

But that's completely backwards from the risk/reward curve for
committers, and it's no wonder clashes here are so common. The idea of
committing something that may not be perfect yet is a lot easier to
stomach if there's plenty of time left in the release cycle for testing
it. Even a full reversion is straightforward to handle when something
is changed early in the release. In a risk adverse project like this
one, the last batch of feature commits for a release should be extremely
picky about what they accept.

On a related note, one reason I'm not quite as concerned about the 9.2
schedule is that none of the more speculative submissions went in near
the end this time. The changes that scare me most have been committed
for months already. That was surely not the case for the last month of
9.0 or 9.1 development, where some pretty big and disruptive things
didn't land until very late.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com