Remind developers to not expose private email addresses, as some people
become upset if their addresses end up in the lore archives or the Linux
git tree.
While at it, explicitly mention the dangers of our bugzilla instance
here, as it makes it easy to forget that email addresses visible there
are only shown to logged-in users.
These are not a theoretical issues, as one maintainer mentioned that
his employer received a EU GDPR (general data protection regulation)
complaint after exposuring a email address used in bugzilla through a
tag in a patch description.
Signed-off-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx>
---
Note: this triggers a few checkpatch.pl complaints that are irrelevant
when when ti comes to changes like this.
v1:
- initial version
---
Documentation/process/5.Posting.rst | 17 +++++++++---
Documentation/process/submitting-patches.rst | 27 +++++++++++++++++---
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
index b3eff03ea2491c..1f6942948db349 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -264,10 +264,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.
+Note, remember to respect other people's privacy when adding these tags:
+
+ - Only specify email addresses, if owners explicitly permitted their use or
+ are fine with exposing them to the public based on previous actions found in
+ the lore archives. In practice you therefore often will be unable to hastily
+ specify addresses for users of bug trackers, as those usually do expose the
+ email addresses at all or only to logged in users. The latter is the case
+ for bugzilla.kernel.org, whose privacy policy explicitly states that 'your
+ email address will never be displayed to logged out users'.
+
+ - 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 given the
+ above constraints, but ask for permission for bugs reported in private.
Sending the patch
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 1518bd57adab50..3373ba3025d6d8 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -484,7 +484,9 @@ 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.
+have been included in the discussion. Note, ensure owners of email addresses
+are fine with exposing their addresses in tags like this; see 'Privacy aspects
+when using tags...' 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 +532,10 @@ 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, ensure owners of email
+addresses are fine with exposing their addresses in tags like this; see
+'Privacy aspects when using tags...' below for details. And if the bug was
+reported in private, ask for permission first before using the Reported-by-tag.
A Tested-by: tag indicates that the patch has been successfully tested (in
some environment) by the person named. This tag informs maintainers that
@@ -600,6 +603,22 @@ process nor the requirement to Cc: stable@xxxxxxxxxxxxxxx on all stable
patch candidates. For more information, please read
Documentation/process/stable-kernel-rules.rst.
+Privacy aspects when using tags like Cc:, Reported-by:, Tested-by:, ...
+-----------------------------------------------------------------------
+
+Only specify email addresses, if owners explicitly permitted their use or
+are fine with exposing them to the public based on previous actions found in
+the lore archives. In practice you therefore often will be unable to blindly
+specify addresses for users of bug trackers, as those usually do expose the
+email addresses at all or only to logged in users. The latter is the case
+for bugzilla.kernel.org, whose privacy policy explicitly states that 'your
+email address will never be displayed to logged out users'.
+
+Furthermore note that 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 given the above constraints, but ask for permission for bugs
+reported in private.
+
.. _the_canonical_patch_format:
The canonical patch format
base-commit: 623e5747c680d3854b6b9882d9907096bc63580d
--
2.45.0
