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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
