Em Mon, 2 Dec 2024 09:14:19 +0100 Thorsten Leemhuis <linux@xxxxxxxxxxxxx> escreveu: > Point out that explicit permission is usually needed to tag other people > in changes, but mention that implicit permission can be sufficient in > certain cases. This fixes slight inconsistencies between Reported-by: > and Suggested-by: and makes the usage more intuitive. > > While at it, explicitly mention the dangers of our bugzilla instance, as > it makes it easy to forget that email addresses visible there are only > shown to logged-in users. > > The latter is not a theoretical issue, as one maintainer mentioned that > his employer received a EU GDPR (general data protection regulation) > complaint after exposing a email address used in bugzilla through a tag > in a patch description. > > Cc: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > Cc: Simona Vetter <simona.vetter@xxxxxxxx> > Cc: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx> LGTM. Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> > --- > Note: this triggers a few checkpatch.pl complaints that are irrelevant > when when to comes to changes like this. > > v3: > - try yet again from a slightly different angle which loosens the rules > slightly. This from review feedback to earlier versions is apparently > what other developers want and from their "no lawyer" perspective > consider to be okay. As IANAL myself I don't feel totally comfortable > with this and have no idea if this legally is sound, so tag patch with > "DONOTMERGE" for now; will remove this for v4 if enough people add a > "Reviewed-by". Otherwise the story of this patch might end here, unless > someone else submits it for inclusion (you are free to do so!). > - remote patch adding Suggested-by: tag to 5.Posting and submit it > separately > > v2: https://lore.kernel.org/all/cover.1731749544.git.linux@xxxxxxxxxxxxx/ > - Retry differently. This slightly hardens the rule for Reported-by: > while slightly lessening it for Suggested-by:. Those in the end are > quite similar, so it does not make much sense to apply different ones. > I considered using an approach along the lines of "if you reported it > in pubic by mail, implicit permission to use in a tag is granted"; but > I abstained from it, as I assume there are good reasons for the > existing approach regarding Suggested-by:. > - CC all the people that provided feedback on the text changes in v1 > > v1: https://lore.kernel.org/all/f5bc0639a20d6fac68062466d5e3dd0519588d08.1731486825.git.linux@xxxxxxxxxxxxx/ > - initial version > --- > Documentation/process/5.Posting.rst | 13 +++++-- > Documentation/process/submitting-patches.rst | 39 ++++++++++++++------ > 2 files changed, 36 insertions(+), 16 deletions(-) > > diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst > index b3eff03ea2491c..73961565040ed8 100644 > --- a/Documentation/process/5.Posting.rst > +++ b/Documentation/process/5.Posting.rst > @@ -264,10 +264,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 tags to your patches, as all except for Cc:, > +Reported-by:, and Suggested-by: need explicit permission of the person named. > +For the three aforementioned ones 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. > > > Sending the patch > diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst > index 1518bd57adab50..9d26a4b7ca8ba3 100644 > --- a/Documentation/process/submitting-patches.rst > +++ b/Documentation/process/submitting-patches.rst > @@ -481,10 +481,10 @@ list archives. > > 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 > @@ -530,9 +530,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 > @@ -582,11 +582,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 > @@ -600,6 +600,21 @@ process nor the requirement to Cc: stable@xxxxxxxxxxxxxxx on all stable > patch candidates. For more information, please read > Documentation/process/stable-kernel-rules.rst. > > +.. _tagging_people: > + > +Tagging people requires permission > +---------------------------------- > + > +Be careful in the addition of tags to your patches, as all except for Cc:, > +Reported-by:, and Suggested-by: need explicit permission of the person named. > +For the three aforementioned ones 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: 83a474c11e8cb59e230a43365cb42fa00d3bddaa Thanks, Mauro
