[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250112152946.761150-3-ojeda@kernel.org>
Date: Sun, 12 Jan 2025 16:29:45 +0100
From: Miguel Ojeda <ojeda@...nel.org>
To: Jonathan Corbet <corbet@....net>
Cc: workflows@...r.kernel.org,
linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
patches@...ts.linux.dev,
Miguel Ojeda <ojeda@...nel.org>,
Neal Gompa <neal@...pa.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>
Subject: [PATCH 2/3] docs: submitting-patches: clarify difference between Acked-by and Reviewed-by
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
Powered by blists - more mailing lists