On Thu, Feb 06, 2025 at 03:30:10PM +0100, Thorsten Leemhuis wrote: > diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst > index dbb763a8de901d..22fa925353cf54 100644 > --- a/Documentation/process/5.Posting.rst > +++ b/Documentation/process/5.Posting.rst > @@ -268,10 +268,15 @@ The tags in common use are: > - Cc: the named person received a copy of the patch and had the > opportunity to comment on it. > > -Be careful in the addition of tags to your patches, as only Cc: is appropriate > -for addition without the explicit permission of the person named; using > -Reported-by: is fine most of the time as well, but ask for permission if > -the bug was reported in private. > +Be careful in the addition of the aforementioned tags to your patches, as all > +except for Cc:, Reported-by:, and Suggested-by: need explicit permission of the > +person named. For those three implicit permission is sufficient if the person > +contributed to the Linux kernel using that name and email address according > +to the lore archives or the commit history -- and in case of Reported-by: > +and Suggested-by: did the reporting or suggestion in public. Note, > +bugzilla.kernel.org is a public place in this sense, but email addresses > +used there are private; so do not expose them in tags, unless the person > +used them in earlier contributions. So for example I can only include Tested-by: when a contributor who tested my patch explicitly offer the tag by replying to it i.e. with the tag, right? > > > Sending the patch > diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst > index 8fdc0ef3e604f4..72f6de419ccc4c 100644 > --- a/Documentation/process/submitting-patches.rst > +++ b/Documentation/process/submitting-patches.rst > @@ -495,10 +495,10 @@ 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. > -This is the only tag which might be added without an explicit action by the > -person it names - but it should indicate that this person was copied on the > -patch. This tag documents that potentially interested parties > -have been included in the discussion. > +This tag documents that potentially interested parties have been included in > +the discussion. Note, this is one of only three tags you might be able to use > +without explicit permission of the person named (see 'Tagging people requires > +permission' below for details). > > Co-developed-by: states that the patch was co-created by multiple developers; > it is used to give attribution to co-authors (in addition to the author > @@ -544,9 +544,9 @@ hopefully inspires them to help us again in the future. The tag is intended for > bugs; please do not use it to credit feature requests. The tag should be > followed by a Closes: tag pointing to the report, unless the report is not > available on the web. The Link: tag can be used instead of Closes: if the patch > -fixes a part of the issue(s) being reported. Please note that if the bug was > -reported in private, then ask for permission first before using the Reported-by > -tag. > +fixes a part of the issue(s) being reported. Note, the Reported-by tag is one > +of only three tags you might be able to use without explicit permission of the > +person named (see 'Tagging people requires permission' below for details). > > A Tested-by: tag indicates that the patch has been successfully tested (in > some environment) by the person named. This tag informs maintainers that > @@ -596,11 +596,11 @@ Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned > in the patch changelog (after the '---' separator). > > A Suggested-by: tag indicates that the patch idea is suggested by the person > -named and ensures credit to the person for the idea. Please note that this > -tag should not be added without the reporter's permission, especially if the > -idea was not posted in a public forum. That said, if we diligently credit our > -idea reporters, they will, hopefully, be inspired to help us again in the > -future. > +named and ensures credit to the person for the idea: if we diligently credit > +our idea reporters, they will, hopefully, be inspired to help us again in the > +future. Note, this is one of only three tags you might be able to use without > +explicit permission of the person named (see 'Tagging people requires > +permission' below for details). > > A Fixes: tag indicates that the patch fixes an issue in a previous commit. It > is used to make it easy to determine where a bug originated, which can help > @@ -618,6 +618,21 @@ Finally, while providing tags is welcome and typically very appreciated, please > note that signers (i.e. submitters and maintainers) may use their discretion in > applying offered tags. > > +.. _tagging_people: > + > +Tagging people requires permission > +---------------------------------- > + > +Be careful in the addition of the aforementioned tags to your patches, as all > +except for Cc:, Reported-by:, and Suggested-by: need explicit permission of the > +person named. For those three implicit permission is sufficient if the person > +contributed to the Linux kernel using that name and email address according > +to the lore archives or the commit history -- and in case of Reported-by: > +and Suggested-by: did the reporting or suggestion in public. Note, > +bugzilla.kernel.org is a public place in this sense, but email addresses > +used there are private; so do not expose them in tags, unless the person > +used them in earlier contributions. > + > .. _the_canonical_patch_format: > > The canonical patch format > > base-commit: e8bcda12176c47f2ce6c5104955845d028a640e8 The wording looks OK. Reviewed-by: Bagas Sanjaya <bagasdotme@xxxxxxxxx> -- An old man doll... just what I always wanted! - Clara
Attachment:
signature.asc
Description: PGP signature
