On Tue, 15 May 2007, Jim C. Nasby wrote:
> Speaking of reviewers... should we put some thought into how we can
> increase the number of people who can review code? It seems that's one
> of our biggest bottlenecks...
Having recently dragged myself from never seeing the code before to being
able to provide an early review to help the committers out, I can tell you
a few things that would have sped up that process and therefore improve
the odds more people will navigate the trail.
My main difficulty was figuring out a workable way to build a local mirror
of the code (so I could get off-line diffs), keep it in sync with the
development tree, while branching out working areas to evaluate patches or
do new development in. A good example walkthrough of how to do that using
standard tools would be a big help. Hint: if you suggest CVsup I'll
smack you.
Overall, though, I don't think there would have been any substitute for
what I learned by putting together my own small patches, so in some
respects thinking about how to lower the bar for doing that would also
ultimately expand the review pool. The main issues I had as a newcomer to
the codebase was getting data in/out of the new code I added that was
buried inside the system. Here are some examples of what I kept
hoping to find documentation on:
-Examples and usage guidelines for eLog and eReport (the stuff in the FAQ
needs some more meat)
-How to add a GUC variable. Once I've got that, now I can adjust the code
in real-time just by updating it.
-How to add to the statistics for some part of the system that track a new
variable and follow how that moves through the collector process.
If you put people into a position where they easily can poke data in at
one end, see how it rattles around inside the engine by logging, and get
some statistics on the result, now you've got someone who can build their
own simple patches without being so frustrated.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
