Re: RFC: reviewer's statement of oversight

On Mon, Oct 08, 2007 at 01:33:38PM -0700, H. Peter Anvin wrote:
Uhm, no. There is no reason an "unimportant" person couldn't review a
patch, and therefore perform a potentially highly valuable service to
the maintainer.

None of these are indicative of the authority of the person acking,
reviewing, testing, or nacking. That's only as good as the trust in the
person signing.

I would tend to agree. Right now I think the problem is that we are
getting too little reviews, not enough. And someone who reviews
patches, even if unknown, could be building up expertise that
eventually would make them a valued developer, even while they are
doing us a service.

The concern that I suspect some people have is what if this gets
abused by people who don't really bother to do a full review of a
patch before they ack it. We could ask reviewers to include a URL to
an LKML archive of their review, to make it easier to find a review of
a patch so later on people can judge how effective they their review
was. Unfortunately, this would be an added burden for the regular
reviewers, so I doubt this would be well accepted as a practice. My
suggestion is to not worry about this for now, and see how well it
works out in practice. If we start getting half a dozen or more
Reviewed-by: where the patch is pretty clearly not getting adequately
reviewed, or where someone is obviously abusing the system, and social
pressures aren't working, we can try to figure out then how we want to
address that problem then. Let's not make the process too complicated
unless we know it's necessary. Premature complexity is almost as bad
as premature optimization....

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: How to improve the quality of the kernel?
    ... IMO we should concentrate more on preventing regressions than on fixing them. ... Over two years ago I've reviewed some _cleanup_ patch and noticed three bugs ... Ignore reviewers - fix the bugs but don't credit reviewers (crediting them ... review the patch than to make it so getting near to zero credit for review ...
    (Linux-Kernel)
  • Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24
    ... I was about to post v2 of my patch to avoid port space collisions with the native stack. ... I've tried to solicit review on it, but I think folks are reluctant... ... Pradeep's IPoIB CM support for devices that don't have SRQs. ... Certainly we want to fix this ...
    (Linux-Kernel)
  • Re: How to improve the quality of the kernel?
    ... There are not so simple cases like big infrastructure patches with ... "If the patch introduces a new regression" ... review the patch than to make it so getting near to zero credit for review ...
    (Linux-Kernel)
  • Re: new ARP code review
    ... L>> Q> Please review my new ARP patch and send me your feedbacks. ... L>> and I will try to find a free time to review your patch again. ... This lookup returns us the hardware address that this IP ...
    (freebsd-net)
  • Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]
    ... The changelog in your earlier "Clustering indirect blocks in Ext3" ... patch was good. ... Here's a quick low-levelish nitpickingish implementation review. ... user-hostile BUG. ...
    (Linux-Kernel)