Message-ID: <20241116141639.5adb4a95@foz.lan>
Date: Sat, 16 Nov 2024 14:16:39 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Thorsten Leemhuis <linux@...mhuis.info>
Cc: Greg KH <gregkh@...uxfoundation.org>, Jonathan Corbet <corbet@....net>,
 workflows@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, Laurent Pinchart
 <laurent.pinchart@...asonboard.com>, Simona Vetter <simona.vetter@...ll.ch>
Subject: Re: [PATCH v2 2/2] docs: clarify rules wrt tagging other people

Em Sat, 16 Nov 2024 13:27:44 +0100
Thorsten Leemhuis <linux@...mhuis.info> escreveu:

> On 16.11.24 12:50, Mauro Carvalho Chehab wrote:
> > Em Sat, 16 Nov 2024 11:42:06 +0100
> > Greg KH <gregkh@...uxfoundation.org> escreveu:  
> >> On Sat, Nov 16, 2024 at 10:33:59AM +0100, Thorsten Leemhuis wrote:  
> >>> 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@...asonboard.com>
> >>> Cc: Simona Vetter <simona.vetter@...ll.ch>
> >>> Cc: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
> >>> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.info>
> >>> ---
> >>> Note: this triggers a few checkpatch.pl complaints that are irrelevant
> >>> when when to comes to changes like this.
> >>>
> >>> v2:
> >>> - 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@leemhuis.info/
> >>> - initial version
> >>> ---
> >>>  Documentation/process/5.Posting.rst          | 17 ++++++--
> >>>  Documentation/process/submitting-patches.rst | 44 ++++++++++++++------
> >>>  2 files changed, 45 insertions(+), 16 deletions(-)
> >>>
> >>> diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
> >>> index dbb763a8de901d..b45c4f6d65ca95 100644
> >>> --- a/Documentation/process/5.Posting.rst
> >>> +++ b/Documentation/process/5.Posting.rst
> >>> @@ -268,10 +268,19 @@ 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 nearly all of them need
> >>> +explicit permission of the person named.
> >>> +
> >>> +The only exceptions are Cc:, Reported-by:, and Suggested-by:, as for them    
> >>
> >> I don't understand what you mean by "only exceptions" here.  Exceptions
> >> to what?
> >>  
> >>> +implicit permission is sufficient under the following circumstances: when the
> >>> +person named according to the lore archives or the commit history regularly
> >>> +contributes to the Linux kernel using that name and email address --   
> > 
> > Note that get_maintainer.pl doesn't use a concept of "regularly", and it
> > doesn't really matter if one has just one or dozens of patches, once it 
> > has a patch merged with his address, it is now public, as git log will
> > keep it forever.
> > 
> > Also, if a patch authored by "John Doe <john@doe>" causes a regression, 
> > a patch fixing the regression should be Cc: to him, even it it was his
> > first contribution.
> > 
> > So, having a single patch accepted is enough to have other patches
> > with meta-tag pointing to a name/email.
> > 
> > So, this would be better:
> > 
> > 	... or the git commit history contains that name and email address  
> 
> Good point. But we are getting closer and closer to areas where I feel
> out of my league as IANAL without any backing from company lawyers if
> this leads to problems down the road.
> 
> To still feel comfortable, I would change this to something like:
> """
> ... or a commit with a 'Signed-off-by' tag containing that name and
> email address.
> """

You should also cover commit authorship, as SOB e-mail might be
different. Currently, -next catches it as warnings, but still
there are cases where maintainer might opt to keep as is, for
instance when the SOB has name+company@...ail and the author
may have just name@...ail - or vice-versa.

What about:

"""
commit with a 'Signed-off-by' tag or patch(es) authored or committed by 
that name and email address.
"""

> Because one accidental expose of a name and email address (say in a CC:
> tag) by a some other developer should not be enough to allow other
> developers to expose it again. Highly unlikely corner case, yes, but I
> feel better that way. And in the end it should not make much of a
> difference.

IANAL either, but, once someone else exposes a secret publicly, it is
not a secret anymore. You can't be blamed to mention a previously
"secret email" that was now public.

> 
> Ciao, Thorsten
> 



Thanks,
Mauro

Powered by blists - more mailing lists