From: Theodore Tso <tytso@mit.edu>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
Sam Ravnborg <sam@ravnborg.org>, Jonathan Corbet <corbet@lwn.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: RFC: reviewer's statement of oversight
Date: Mon, 8 Oct 2007 17:38:52 -0400 [thread overview]
Message-ID: <20071008213852.GA31713@thunk.org> (raw)
In-Reply-To: <470A9422.4050400@zytor.com>
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
next prev parent reply other threads:[~2007-10-08 21:39 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-08 17:24 RFC: reviewer's statement of oversight Jonathan Corbet
2007-10-08 17:31 ` Pekka Enberg
2007-10-08 17:37 ` Sam Ravnborg
2007-10-08 17:45 ` Jan Engelhardt
2007-10-08 18:01 ` Jeremy Fitzhardinge
2007-10-08 18:06 ` Randy Dunlap
2007-10-08 18:16 ` Jeremy Fitzhardinge
2007-10-08 18:34 ` Stefan Richter
2007-10-08 18:52 ` J. Bruce Fields
2007-10-08 19:04 ` Stefan Richter
2007-10-08 19:26 ` Scott Preece
2007-10-08 20:16 ` Rafael J. Wysocki
2007-10-09 2:07 ` Steven Rostedt
2007-10-09 6:11 ` Stefan Richter
2007-10-09 6:27 ` Sam Ravnborg
2007-10-09 6:39 ` Stefan Richter
2007-10-09 6:47 ` Stefan Richter
2007-10-08 18:26 ` Stefan Richter
2007-10-08 18:40 ` Roland Dreier
2007-10-08 19:35 ` Scott Preece
2007-10-08 20:33 ` H. Peter Anvin
2007-10-08 21:38 ` Theodore Tso [this message]
2007-10-08 22:18 ` Rafael J. Wysocki
2007-10-08 23:20 ` Oleg Verych
2007-10-08 22:43 ` Jonathan Corbet
2007-10-08 23:06 ` Randy Dunlap
2007-10-09 3:34 ` Stephen Hemminger
2007-10-08 23:30 ` J. Bruce Fields
2007-10-09 10:28 ` Alan Cox
2007-10-08 23:42 ` Stefan Richter
2007-10-09 0:05 ` Neil Brown
2007-10-09 16:49 ` Jonathan Corbet
2007-10-09 17:25 ` Roland Dreier
2007-10-10 0:06 ` David Chinner
2007-10-15 0:27 ` Neil Brown
2007-10-09 17:44 ` Sam Ravnborg
2007-10-15 0:35 ` Neil Brown
2007-10-15 14:32 ` Sam Ravnborg
2007-10-10 13:40 ` Scott Preece
2007-10-08 18:40 ` Mark Gross
2007-10-08 18:53 ` Stefan Richter
2007-10-08 19:05 ` Al Viro
2007-10-08 19:08 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071008213852.GA31713@thunk.org \
--to=tytso@mit.edu \
--cc=corbet@lwn.net \
--cc=hpa@zytor.com \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox