Re: Patch committers - Mailing list pgsql-hackers

(I'm not sure I should piping up here, so feel free to ignore, but
perhaps I have something small to offer. I've been following the list
for a while, but try to keep my mouth shut.)

On 13/11/2009 3:07 AM, Selena Deckelmann wrote:

> * Distributed revision control as standard for the project

This would also make it a lot easier to track in-progress work on
particular features of interest, allowing interested users to help with
advance testing of early versions of major feature work. Chasing patches
on a mailing list is not an attractive way to try to keep up with
someone's in-progress work, and is demotivating to people interested in
testing that work. Think: HOT, warm standby, etc.

It also helps with the issue where a patch is posted, followed by short
thread of corrections and changes you have to manually apply to reach
(you hope) the same codebase others are testing. Sure, sometimes a
follow-up patch is posted with the changes, but often not.



I also found one comment of Tom Lane's really interesting:

> The question is how to do an adequate job of reviewing
> their patches, when only a fraction of the existing committers are
> willing to put time into reviewing other people's patches.  (Let's face
> it, that's a lot less fun than writing your own code.)

Perhaps I'm strange, but I personally enjoy patch review. I often think
others are smarter and better at creative, new development - but their
work often needs polish and cleanup, makes mistakes with internal APIs,
etc. It feels like something I can contribute usefully, and it's a role
I've had in PoDoFo among other projects. I naturally gravitate toward
cleanup and patch review, but I'm not generally much good at major
feature work.

Is it possible that it's worth inviting committers who're primarily
interested in patch review, not their own original work? I'd be
surprised if there weren't interested, competent people. I might be one
of them if I didn't fail quite so profoundly on the latter point. If
somebody isn't feeling constantly frustrated by the perceived burden of
reviewing others' work taking time out of their own, they might be less
prone to burn-out.

As for gaining the required competence without doing a lot of first-hand
development on the codebase: Much as a committer may focus mainly on one
area of Pg's codebase and may not be competent to make unsupervised /
unassisted changes in another, surely patch reviewer-committers could
also have a few areas of interest and focus on patches touching those
areas? Especially with review of patches by several different people
with different areas of interest touched on by a given patch, it may not
require globally competent reviewers to ensure good patch quality.

--
Craig Ringer