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: <CAEg-Je81VAYecajUjYVJKBJUT+YqKemWsWEoWFgOcF=vtfPRPw@mail.gmail.com>
Date: Sun, 12 Jan 2025 10:50:32 -0500
From: Neal Gompa <neal@...pa.dev>
To: 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, 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.


-- 
真実はいつも一つ!/ Always, there's only one truth!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ