On Wed, Apr 11, 2012 at 16:24, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Smith <greg@2ndQuadrant.com> writes:
>> 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?
>
>> ...
>> 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.
>
> Well, with all due respect, that does not sound like a change that
> doesn't need review.
>
> I have not noticed people adding docs-only changes to the CFs; usually
> it's more like "post a patch, somebody looks it over and commits it".
> I agree that this is still too much overhead for simple fixes, such
> as the editorial glitches that Thom Brown is so good at finding
> (and I'm about ready to vote to give him a commit bit for that work).
> But a fifty-page chunk is not that, indeed it sounds like it would have
> enough technical content that it might actually merit a full-scale
> review.
Since the topic is somewhat drifting here anyway.. :-)
Might it be worthwhile to allow some sort of "staging repository" and
actually start using the git stuff a bit more around this? E.g. we
could have a "docs repo" somewhere where more people have commit bits,
and then they are just regularly merged back into the main tree? Sort
of the way different people can own different subsystems in other
projects, but someone does the "trusted merge"?
For example, Thom (and others) could collect a number of typo fixes in
their own repo and then just ask for a merge.The advantage over just
staging multiple commits and then submitting a patch would be that
multiple people could work on it...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
