Message-ID: <20241116125003.43bf305c@foz.lan>
Date: Sat, 16 Nov 2024 12:50:03 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Thorsten Leemhuis <linux@...mhuis.info>, 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 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

> > and in
> > +case of Reported-by: and Suggested-by: did the reporting or suggestion in
> > +public. For all other situations explicit permission is required to among
> > +others prevent exposing email addresses considered private. Especially ask for
> > +permission when it comes to bug trackers, as most only show addresses to logged
> > +in users; that includes bugzilla.kernel.org, whose privacy policy explicitly
> > +states that 'your email address will never be displayed to logged out users'.
> 
> How about makeing this much simpler, basically "any public reference can
> be used, but please note, email addresses in bugzilla.kernel.org are not
> public.  Anything offered in private should probably not be referenced."

This works too.

> or something like that?
> 
> thanks,
> 
> greg k-h
> 



Thanks,
Mauro

Powered by blists - more mailing lists