public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	mathieu.desnoyers@polymtl.ca, linux-kernel@vger.kernel.org
Subject: Re: [patch 1/6] Linux Kernel Markers - Architecture Independent Code
Date: Fri, 7 Sep 2007 12:04:45 -0400	[thread overview]
Message-ID: <20070907160445.GB8911@thunk.org> (raw)
In-Reply-To: <20070906163737.9cc91307.randy.dunlap@oracle.com>

On Thu, Sep 06, 2007 at 04:37:37PM -0700, Randy Dunlap wrote:
> Thanks.  I look forward to the explanation of Reviewed-by, what it
> means, and how it differs from Acked-by.

This was proposed by Andrew and discussed at the Kernel Summit; the
basic idea is that it is a formal indication that the person has done
a *full* review of the patch (a few random comments from the local
whitespace police don't count), and is willing to vouch that the patch
is correct, safe, extremely unlikely to cause regressions, etc.  If
the patch does need to be reverted or fixed because it was buggy, then
both the original submitter and the reviewer would bear responsibility
and subsystem maintainers might take that into account when assessing
the reputations of the submitter and reviewer in the future when
deciding whether or not to accept a patch.

Basically, some people seem to be using "Acked-by" to mean, "seems
good to me", without necessarily doing a full review of the patch, and
instead of trying to change the meaning of "Acked-by", to have a new
sign off which is a bit more explicitly about what it means.  (Hmmm,
thinking about it afterwards, maybe "Vouched-by:" would be even
better....)

There was some thought about negative attention (i.e., "public
mockery") given to people who sign off on a patch via Reviewed-by:
that subsequently turns out to be buggy or cause a regression, but the
concern with that is that we have enough trouble finding people to
review patches, and we wouldn't want to scare off reviewers.  But it
would be fair to say that the consequences of reviewing patches
successfully or unsuccessfully would naturally impact people's
reputations.

There was also some discussion about whether or not patches would not
be accepted at all without a Reviewed-by, but that probably won't
happen initially.  The general consensus was to gently ease into it
and see how well it works first.

        					- Ted

  parent reply	other threads:[~2007-09-07 16:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-06 20:07 [patch 0/6] Linux Kernel Markers for 2.6.23-rc4-mm1 Mathieu Desnoyers
2007-09-06 20:07 ` [patch 1/6] Linux Kernel Markers - Architecture Independent Code Mathieu Desnoyers
2007-09-06 23:00   ` Randy Dunlap
2007-09-06 23:04     ` Andrew Morton
2007-09-06 23:37       ` Randy Dunlap
2007-09-07  4:05         ` Valdis.Kletnieks
2007-09-07  4:11           ` Randy Dunlap
2007-09-07 16:04         ` Theodore Tso [this message]
2007-09-07 17:10           ` Valdis.Kletnieks
2007-09-07 19:31             ` Christoph Hellwig
2007-09-07 21:30               ` Roland Dreier
2007-09-07 13:01     ` Mathieu Desnoyers
2007-09-06 20:07 ` [patch 2/6] Linux Kernel Markers - Add kconfig menus for the marker code Mathieu Desnoyers
2007-09-06 23:35   ` Randy Dunlap
2007-09-12 14:54     ` Mathieu Desnoyers
2007-09-06 20:07 ` [patch 3/6] Linux Kernel Markers - Documentation Mathieu Desnoyers
2007-09-06 23:48   ` Randy Dunlap
2007-09-06 20:07 ` [patch 4/6] Linux Kernel Markers - Documentation Fix Mathieu Desnoyers
2007-09-06 20:07 ` [patch 5/6] Port of blktrace to the Linux Kernel Markers Mathieu Desnoyers
2007-09-06 20:07 ` [patch 6/6] Linux Kernel Markers - Port SPU to markers Mathieu Desnoyers
2007-09-08  7:04   ` Alexey Dobriyan
2007-09-08  7:23     ` Mathieu Desnoyers
2007-09-08 12:11   ` Christoph Hellwig

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=20070907160445.GB8911@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=randy.dunlap@oracle.com \
    /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