linux-kernel - Re: [PATCH 2/3] docs: submitting-patches: clarify difference between Acked-by and Reviewed-by

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: <87ikqij3dj.fsf@intel.com>
Date: Mon, 13 Jan 2025 14:38:00 +0200
From: Jani Nikula <jani.nikula@...el.com>
To: Neal Gompa <neal@...pa.dev>, Miguel Ojeda <ojeda@...nel.org>
Cc: Jonathan Corbet <corbet@....net>, workflows@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 patches@...ts.linux.dev, Sami Tolvanen <samitolvanen@...gle.com>, Masahiro
 Yamada <masahiroy@...nel.org>, Luis Chamberlain <mcgrof@...nel.org>,
 tech-board@...ups.linuxfoundation.org, Steven Rostedt
 <rostedt@...dmis.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Linus
 Torvalds <torvalds@...ux-foundation.org>, Shuah Khan
 <skhan@...uxfoundation.org>, Dan Williams <dan.j.williams@...el.com>,
 "Darrick J. Wong" <djwong@...nel.org>
Subject: Re: [PATCH 2/3] docs: submitting-patches: clarify difference
 between Acked-by and Reviewed-by

On Sun, 12 Jan 2025, Neal Gompa <neal@...pa.dev> wrote:
> On Sun, Jan 12, 2025 at 10:30 AM Miguel Ojeda <ojeda@...nel.org> wrote:
>>
>> Newcomers to the kernel need to learn the different tags that are
>> used in commit messages and when to apply them. Acked-by is sometimes
>> misunderstood, since the documentation did not really clarify (up to
>> the previous commit) when it should be used, especially compared to
>> Reviewed-by.
>>
>> The previous commit already clarified who the usual providers of Acked-by
>> tags are, with examples. Thus provide a clarification paragraph for
>> the comparison with Reviewed-by, and give a couple examples reusing the
>> cases given above, in the previous commit.
>>
>> Acked-by: Shuah Khan <skhan@...uxfoundation.org>
>> Acked-by: Dan Williams <dan.j.williams@...el.com>
>> Signed-off-by: Miguel Ojeda <ojeda@...nel.org>
>> ---
>>  Documentation/process/submitting-patches.rst | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
>> index c7a28af235f7..7b0ac7370cb1 100644
>> --- a/Documentation/process/submitting-patches.rst
>> +++ b/Documentation/process/submitting-patches.rst
>> @@ -480,6 +480,12 @@ mergers will sometimes manually convert an acker's "yep, looks good to me"
>>  into an Acked-by: (but note that it is usually better to ask for an
>>  explicit ack).
>>
>> +Acked-by: is also less formal than Reviewed-by:.  For instance, maintainers may
>> +use it to signify that they are OK with a patch landing, but they may not have
>> +reviewed it as thoroughly as if a Reviewed-by: was provided.  Similarly, a key
>> +user may not have carried out a technical review of the patch, yet they may be
>> +satisfied with the general approach, the feature or the user-facing interface.
>> +
>>  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
>> --
>> 2.48.0
>>
>
> This doesn't make sense as a distinction. What defines "thoroughly"?
> To be honest, I think you should go the other way and become okay with
> people sending Reviewed-by tags when people have looked over a patch
> and consider it good to land.
>
> To me, Acked-by mostly makes sense as a tag for people who *won't*
> review the code, not for those who *will*. Blending Acked-by and
> Reviewed-by just creates confusion.

As a maintainer, I mostly use Acked-by for two slightly different cases:

1) I've seen the patch. I have no objections to it being merged, I
   approve of it. I haven't done a detailed review of it. Additionally,
   I may indicate whether a detailed review (by someone else) is
   required, or whether I think the ack is sufficient for merging.

2) I'm fine with the patch to the area I maintain being merged via some
   other maintainers' repositories. I may or may not have also given my
   Reviewed-by in this case, which alone is not an approval to merge via
   other trees.

I think this pretty much aligns with the patch series.

BR,
Jani.

-- 
Jani Nikula, Intel