From: Carlos O'Donell <carlos@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>,
Thomas Schwinge <thomas@codesourcery.com>
Cc: gcc@gcc.gnu.org, Gerald Pfeifer <gerald@pfeifer.com>,
Richard Biener <richard.guenther@gmail.com>,
gdb@sourceware.org, binutils@sourceware.org,
libc-alpha@sourceware.org
Subject: Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.
Date: Fri, 20 Oct 2017 10:36:00 -0000 [thread overview]
Message-ID: <6e450f2e-b34c-1e8f-2f57-b510cbbcf783@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1710191641040.29258@digraph.polyomino.org.uk>
On 10/19/2017 09:45 AM, Joseph Myers wrote:
> On Thu, 19 Oct 2017, Thomas Schwinge wrote:
>
>> Hi!
>>
>> Still waiting for any kind of reaction -- general process-change inertia,
>> chicken-and-egg problem, I suppose. ;-/
>>
>> I have now put the proposed text onto a wiki page, so that those
>> interested have a convenient handle to use,
>> <https://gcc.gnu.org/wiki/Reviewed-by>.
>
> That wiki page refers to Reviewed-by as being about crediting reviewers.
> But the specification appears to be oriented to something else entirely
> (i.e. convincing a committer - in a Linux-kernel-like context with a very
> limited set of committers to a particular tree, much smaller than the set
> of reviewers - that a patch is worthy of commit). It doesn't cover
> reviews that request changes, or only relate to part of a patch, or relate
> to a previous version of a patch - only the limited special case of a
> review approving the entirety of a patch as posted. If the aim is credit,
> a substantially different specification is needed.
This is the purpose of Acked-by: ...
Which we could also include.
linux/Documentation/process/submitting-patches.rst
...
Acked-by: does not necessarily indicate acknowledgement of the entire patch.
For example, if a patch affects multiple subsystems and has an Acked-by: from
one subsystem maintainer then this usually indicates acknowledgement of just
the part which affects that maintainer's code. Judgement should be used here.
When in doubt people should refer to the original discussion in the mailing
list archives.
...
--
Cheers,
Carlos.
next prev parent reply other threads:[~2017-10-19 17:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 16:50 Thomas Schwinge
2017-09-21 17:38 ` Carlos O'Donell
2017-09-21 17:56 ` Richard Biener
2017-09-21 18:18 ` Carlos O'Donell
2017-09-21 18:38 ` Richard Biener
2017-09-21 19:54 ` Carlos O'Donell
2017-09-22 18:38 ` Thomas Schwinge
2017-10-04 13:47 ` Thomas Schwinge
2017-10-19 17:06 ` Thomas Schwinge
2017-10-19 17:08 ` Carlos O'Donell
2017-10-19 22:40 ` Martin Sebor
2017-10-20 10:13 ` Joseph Myers
2017-10-20 10:36 ` Carlos O'Donell [this message]
2017-10-20 10:40 ` Carlos O'Donell
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=6e450f2e-b34c-1e8f-2f57-b510cbbcf783@redhat.com \
--to=carlos@redhat.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sourceware.org \
--cc=gerald@pfeifer.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=richard.guenther@gmail.com \
--cc=thomas@codesourcery.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).