Re: [PATCH v4] docs: clarify rules wrt tagging other people

[Bagas Sanjaya]

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