From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Last gasp |
Date: | 2012-04-15 22:11:48 |
Message-ID: | 4F8B47A4.8060903@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2012-04-15 22:18:20 | Re: Last gasp |
Previous Message | Noah Misch | 2012-04-15 20:15:35 | Re: how to create a non-inherited CHECK constraint in CREATE TABLE |