On Sun, Jan 12, 2025 at 04:29:44PM +0100, Miguel Ojeda wrote: > 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@xxxxxxxxxxxxxx/ [1] > Acked-by: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> > Acked-by: Dan Williams <dan.j.williams@xxxxxxxxx> > Signed-off-by: Miguel Ojeda <ojeda@xxxxxxxxxx> > --- > Documentation/process/submitting-patches.rst | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst > index 1518bd57adab..c7a28af235f7 100644 > --- a/Documentation/process/submitting-patches.rst > +++ b/Documentation/process/submitting-patches.rst > @@ -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 > 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. > > +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@xxxxxxxxxxx> # As primary user > + > 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 > 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 > 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. > +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 > provided such comments, you may optionally add a ``Cc:`` tag to the patch. > -- > 2.48.0 Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
