(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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers