On 04/10/2012 09:14 PM, Robert Haas wrote:
I wouldn't object to creating some doc-only committers. OTOH, I would
object to anyone making non-trivial documentation enhancements without
posting their patches first and having a second person look it over,
so how much difference is there, really?
This workflow is the easy one:
-Committer suggests doc change
-No one has an opinion against it strong enough to comment, or minor
review comments are made
-Commit change with feedback when received
That's a predictable, short process unless the change is controversial,
in which case good feedback normally comes out of that discussion. And
if I feel review is needed but don't catch any volunteers, there is a
much broader pool of people who can be hired to help with review work,
relative to the size of the committer one.
Compare with:
-Submitter suggests doc change
-No one has a strong opinion on it, may not be picked up at all
-Submitter adds to the next CF
-Wait for review
-[Possible repost update with reviewer changes]
-Ready for committer
-Committer takes time away from code review to look at it
-Possibly another feedback/review resubmission
-Commit final versions
It's usually not this bad, but in every case it's pulling resources off
of more valuable jobs.
I'd like to dump around 50 pages of new material into the docs as a
start, but I don't want to take so much time away from the code oriented
committers to chew on that much.
--
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
