Em Sat, 16 Nov 2024 11:42:06 +0100 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> > > Cc: Simona Vetter <simona.vetter@xxxxxxxx> > > Cc: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> > > Signed-off-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx> > > --- > > 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@xxxxxxxxxxxxx/ > > - 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
