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
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.
to post comments)