linux-kernel - Re: RFC: reviewer's statement of oversight

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200710090018.40061.rjw@sisk.pl>
Date:	Tue, 9 Oct 2007 00:18:39 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Theodore Tso <tytso@....edu>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Sam Ravnborg <sam@...nborg.org>,
	Jonathan Corbet <corbet@....net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: RFC: reviewer's statement of oversight

On Monday, 8 October 2007 23:38, Theodore Tso wrote:
> 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....

I agree.

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