Too many Cc's [LWN.net]

By Jonathan Corbet
September 8, 2010

In kernel-related email communications, the general rule is to err on the side of sending copies to too many recipients rather than too few. The volume on the mailing lists is such that one can never assume that interested people will see any specific message there, so it's customary to copy people explicitly. Recently, though, a number of kernel developers have started to complain that they are getting copies of patches that they have no interest in. Often, the selection of recipients seems entirely random.

The culprit is the get_maintainer.pl script shipped with the kernel source. This script is actually a useful tool; it will look in the MAINTAINERS file to find the people who might be interested in a specific patch. Potentially less usefully, it will also dig through the repository history and list other developers who have made changes to the files modified by a given patch. So anybody who has tweaked a given file in the recent past - possibly making only trivial changes - will be listed as people to copy on any other patches to the same file.

Looking at the file revision history can, indeed, be a useful way to find the "real" maintainers; the information in MAINTAINERS, instead, can be incomplete or outdated. But, clearly, one needs to look at what a developer has actually done in a given area; fixing a file for an API change does not mean that the developer is actively working on that code. Many developers don't perform that check and, instead, just send mail to everybody listed by the script.

The level of grumpiness caused by widely-broadcast patches seems to be on the rise. Developers who don't want to receive an irritated response to their postings might want to take a little care or, at least, use the --nogit option to get_maintainer.pl.

(Log in to post comments)

Too many Cc's

Posted Sep 9, 2010 15:04 UTC (Thu) by alonz (subscriber, #815) [Link]

It may be nice to enhance get_maintainer.pl so it can take in a patch and only add Cc's on people who actually touched the relevant lines.

Although since I am not volunteering to do it, maybe I should shut up ;)

Too many Cc's

Posted Sep 9, 2010 15:33 UTC (Thu) by dgm (subscriber, #49227) [Link]

Maybe we need a NON-MAINTAINERS (aka DONOTCCME) file?

Too many Cc's

Posted Sep 9, 2010 18:59 UTC (Thu) by jimparis (subscriber, #38647) [Link]

What about adding comments to the email addresses that get-maintainer.pl puts out? E.g.

$ ./scripts/get_maintainer.pl -f arch/mips/kernel/scall64-n32.S
# Note: Please Cc: addresses starting at the top, but don't include
# more than you think are really necessary for this patch.
(Mailing List, primary) linux-mips@linux-mips.org
(Maintainer) Ralf Baechle <ralf@linux-mips.org>
(Mailing List, fallback) linux-kernel@vger.kernel.org
(Recent Commit, 2010/04/04) Christoph Hellwig <hch@lst.de>
(Recent Commit, 2010/03/03) "Eric W. Biederman" <ebiederm@xmission.com>
(Recent Commit, 2010/02/02) Andrew Morton <akpm@linux-foundation.org>
(Recent Commit, 2010/01/01) David Daney <ddaney@caviumnetworks.com>

Assuming your mail client handles RFC2822 properly, you should still be able to just cut and paste those addresses, even with the comments there.

Too many Cc's

Posted Sep 10, 2010 0:37 UTC (Fri) by mhelsley (subscriber, #11324) [Link]

Or how about extending the "Signed-off-by" tags to enable submitters, reviewers, etc. to opt-in to further Cc's?

For example:

Reviewed-by: Matt Helsley <myemail@foo.bar.com> [Related-Cc]

or perhaps make it an explicit tag using the existing formatting:

Related-Cc: Matt Helsley <myemail@foo.bar.com>

This way it's an explicit opt-in and we don't have another file to maintain. A file which, I might add, will always be _incredibly_ out of date and _highly_ context insensitive.

Too many Cc's

Posted Sep 10, 2010 6:56 UTC (Fri) by dmk (subscriber, #50141) [Link]

get_maintainer.pl should do the right thing by default as it is a means to automate/simplify the deployment of a change.

Also it is definitely necessary to cc lkml, because else the patch may fall through the cracks.

Also I didn't know that such a thing existed... A kernel developer that doesn't like receiving email? *g*

Also,
Flo