Re: Signing off of patches (was Re: Not ready for 8.3)

On Fri, May 18, 2007 at 12:05:55PM -0400, Alvaro Herrera wrote:

> there are no obvious, glaring mistakes could go a long way. (I have
> this weird idea that I should not apply a patch unless someone else says
> "hey, looks OK to me". Somehow, the mere lack of objections does not
> increase my confidence.)

I have nothing to contribute on the suggestion, since I can neither
offer review nor patches. But I can offer an analogy that will maybe
strengthen your point, and might offer a hint of how to make the
developer community bigger.

In the IETF working groups I follow, most of the chairs have decided
to impose some baseline level of group review for protocol documents.
In dnsop, for instance, we have a rule that if at least five people
do not review an Internet Draft and agree to its publication, it just
won't get advanced as a working group document. The idea is that, if
we can't get that small number of reviews, then either the working
group either isn't interested in the feature or topic, or the draft
is a bad idea as it stands.

As a result, if you want to have the suasion to get people to review
your own submissions, you also have to do the work of reviewing
others'. But it also means that if you're new to an area, you can
become better in that area by doing document review. Probably, your
own reviews won't uncover big flaws that those more experienced with
the protocol will find; but you'll be able to make some small
contributions that will allow you help in getting the documents
finished. Also, while you're at it, you'll be forced to read all the
referenced documents, which help you learn about the protocol and
therefore make you more valuable to the WG.

Perhaps, then, new contributors to Postgres could also take on the
task of reviewing some of the patches, not as a matter of being the
_only_ reviewer -- the new code still needs review by those more
experienced with the rest of the code -- but as a first-pass review
that will help in a "more eyeballs" sort of way. This would also
have the happy paedogogical effect that those newer reviewers would
learn more of the code in each cycle. I think this is similar to a
previous suggestion someone made about "mentored review", but it
doesn't require formal mentoring for it to get started.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
Users never remark, "Wow, this software may be buggy and hard
to use, but at least there is a lot of code underneath."
--Damien Katz