On 04/14/2012 06:03 PM, Robert Haas wrote:
If someone's work is going to require substantial revision, it is much better and much less work to do that revision before the code goes into our repository (and particularly, before it gets released) rather than after.
I would think one of the major factors in deciding who should be able to commit code is whether they'll likely to commit substandard material. Someone who reviews and is seen to mark patches "ready for commit", and they're not, should surely not be committing things either.
The review process we have now does a pretty good job of identifying which submissions are baked and which aren't. I'd never argue that there should be more people to commit so they can slip in half baked material. Someone doesn't need to know how to bake everything to be useful as a committer though; they just need to know what they can and can't handle.
And, on a related note, I am having a hard time imagining that it's a good idea to give very many people commit bits primarily so that they can commit their own work.
If someone has committed their own work after that submission went through the full CF and review process, I don't see a lot of harm in them committing the result. I'd certainly never suggest that the reason to have more committers is so that the CF workflow was easier to subvert. Yes, there are problems with having enough reviewers and ushering large patches through the CF process. But it seems to me there are a fair number of submission that start solid, turn excellent through thorough review, and once they do hit "ready for committer" they could be picked up for commit by more people than the existing very small pool (committers who process other people's submissions regularly).
Also, and I'm aware this is a more controversial point, I believe there are some people who would do more review if they could just move toward committing the stuff that looks good without going through quite as much process. At some times, if you realize something is close and just needs a bit more work, the easy path is to just do it yourself and be done. Non committing reviewers can't get that efficiency boost in the cases it's appropriate.
-- 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
