Em Sat, 16 Nov 2024 13:27:44 +0100 Thorsten Leemhuis <linux@xxxxxxxxxxxxx> escreveu: > On 16.11.24 12:50, Mauro Carvalho Chehab wrote: > > 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 > > 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@xxxxxx and the author may have just name@xxxxxx - 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
