Re: Last gasp - Mailing list pgsql-hackers

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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com