Re: Last gasp - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Last gasp
Date
Msg-id 4F8B47A4.8060903@2ndQuadrant.com
Whole thread Raw
In response to Re: Last gasp  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: how to create a non-inherited CHECK constraint in CREATE TABLE
Next
From: Greg Smith
Date:
Subject: Re: Last gasp