github-mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-09-23 22:14:03 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity Graph

docs: submitting-patches: clarify Acked-by and introduce "# Suffix"

Browse Source 
Acked-by is typically used by maintainers. However, sometimes it is
useful to be able to accept the tag from other stakeholders that may not
have done a deep technical review or may not be kernel developers. For
instance:

  - People with domain knowledge, such as the original author of the
    code being modified.

  - Userspace-side reviewers for a kernel uAPI patch, like in DRM --
    see Documentation/gpu/drm-uapi.rst:

    > The userspace-side reviewer should also provide an Acked-by on the
    > kernel uAPI patch indicating that they believe the proposed uAPI
    > is sound and sufficiently documented and validated for userspace's
    > consumption.

  - Key users of a feature, such as in [1].

Thus clarify that Acked-by may be used by other stakeholders (but most
commonly by maintainers).

Since, in these cases, it may be confusing why an Acked-by is/was
provided, allow and suggest to provide a "# Suffix" explaining it.

The "# Suffix" for Acked-by is already being used to clarify what part
of the patch a maintainer is acknowledging, thus also mention "# Suffix"
in the relevant paragraph.

Link: https://lore.kernel.org/rust-for-linux/CANiq72m4fea15Z0fFZauz8N2madkBJ0G7Dc094OwoajnXmROOA@mail.gmail.com/ [1]
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250112152946.761150-2-ojeda@kernel.org
This commit is contained in:
Miguel Ojeda 2025-01-12 16:29:44 +01:00 committed by Jonathan Corbet
parent f80aaf40e2
commit cd9123eeb2
1 changed files with 10 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Documentation/process/submitting-patches.rst
View File

@ -463,9 +463,17 @@ If a person was not directly involved in the preparation or handling of a
patch but wishes to signify and record their approval of it then they can patch but wishes to signify and record their approval of it then they can
ask to have an Acked-by: line added to the patch's changelog. ask to have an Acked-by: line added to the patch's changelog.
Acked-by: is often used by the maintainer of the affected code when that Acked-by: is meant to be used by those responsible for or involved with the
affected code in one way or another. Most commonly, the maintainer when that
maintainer neither contributed to nor forwarded the patch. maintainer neither contributed to nor forwarded the patch.
Acked-by: may also be used by other stakeholders, such as people with domain
knowledge (e.g. the original author of the code being modified), userspace-side
reviewers for a kernel uAPI patch or key users of a feature. Optionally, in
these cases, it can be useful to add a "# Suffix" to clarify its meaning::
Acked-by: The Stakeholder <stakeholder@example.org> # As primary user
Acked-by: is not as formal as Signed-off-by:. It is a record that the acker Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
has at least reviewed the patch and has indicated acceptance. Hence patch has at least reviewed the patch and has indicated acceptance. Hence patch
mergers will sometimes manually convert an acker's "yep, looks good to me" mergers will sometimes manually convert an acker's "yep, looks good to me"
@ -477,7 +485,7 @@ For example, if a patch affects multiple subsystems and has an Acked-by: from
one subsystem maintainer then this usually indicates acknowledgement of just one subsystem maintainer then this usually indicates acknowledgement of just
the part which affects that maintainer's code. Judgement should be used here. 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 When in doubt people should refer to the original discussion in the mailing
list archives. list archives. A "# Suffix" may also be used in this case to clarify.
If a person has had the opportunity to comment on a patch, but has not If a person has had the opportunity to comment on a patch, but has not
provided such comments, you may optionally add a ``Cc:`` tag to the patch. provided such comments, you may optionally add a ``Cc:`` tag to the patch.