From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Jonathan Corbet <corbet@lwn.net>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: [PATCH] Documentation/patch-tags v3
Date: Thu, 11 Oct 2007 23:21:23 +0200 [thread overview]
Message-ID: <470E93D3.5050707@s5r6.in-berlin.de> (raw)
In-Reply-To: <1192135811.7899.25.camel@heimdal.trondhjem.org>
Trond Myklebust wrote:
> Does 'Reviewed-by' also imply 'Signed-off-by'?
Does a technical review include a review of licensing and copyright
issues? (It doesn't seem to be a big issue though if the submitter
signed off on it, like he should.)
> In other words, who is actually supposed to add this tag?
>
> Is it the reviewer who passes on an officially 'reviewed' patch to the
> maintainer, or is it the patch author him/herself who is responsible for
> soliciting reviews and adding the tag?
Anybody in the patch forwarding chain (author, maintainers... usually
the latter) can add Acked-by and Tested-by, based on incoming feedback.
The feedback may have explicitly stated an Acked-by or Tested-by or may
have said something equivalent. (In case of Tested-by, an appropriate
description of how was tested should have been sent. An explicit
Tested-by from the tester himself is moot then.)
Reviewed-by is a different beast. If Jon's definition of Reviewed-by
(or another definition) is "officially" adopted, people in the patch
forwarding chain should only add this tag if the reviewer sent it
explicitly in his response. Unlike with Acked-by and Tested-by, we must
not guess whether a reviewer wants to have his Reviewed-by added.
[...]
>> + (c) While there may be things that could be improved with this submission,
>> + I believe that it is, at this time, (1) a worthwhile modification to
>> + the kernel, and (2) free of known issues which would argue against its
>> + inclusion.
>> +
>> + (d) While I have reviewed the patch and believe it to be sound, I do not
>> + (unless explicitly stated elsewhere) make any warranties or guarantees
>> + that it will achieve its stated purpose or function properly in any
>> + given situation.
>
> I'm confused about how to reconcile (c) and (d) here. If you are not
> sure about whether or not the patch will achieve its stated purpose, why
> would you be arguing that it is a worthwhile modification?
Being sure of something and making guarantees are different things.
--
Stefan Richter
-=====-=-=== =-=- -=-==
http://arcgraph.de/sr/
next prev parent reply other threads:[~2007-10-11 21:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-11 20:16 Jonathan Corbet
2007-10-11 20:50 ` Trond Myklebust
2007-10-11 21:07 ` Randy Dunlap
2007-10-11 21:21 ` Stefan Richter [this message]
2007-10-11 21:51 ` Trond Myklebust
2007-10-11 22:11 ` Stefan Richter
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=470E93D3.5050707@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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
all inboxes | Powered by JetHome®