Hello,
(hhm, my MTA failed to send my mail to Denis. I'll try once more.)
Thanks hpa. That would have been roughly my response, too. I can see
Pekka's point, too, but IMHO the advantages outweight the disadvantages.
This might result in some mails that don't reach the complete needed
audience, but it should assert that at least one right person is reached
and this one probably knows who to forward the mail. I expect that in
most cases the automatic answer is right, though.
Continuing planning how to implement such an automation I found that
git-send-email already has an option --cc-cmd=/path/to/some/program.
program is called once per patch and should print email addresses to
stdout. (This is already nearly optimal. The only missing part is that
the addresses should occur in the resulting commit in a Cc: line. This
could be implemented in program, too, but for me it feels wrong to do it
there. IMHO git-send-email would be the better place. I consider this
lower prio, though, so this has to wait (or be done by someone else).)
To go forward with how to specify a file <-> maintainer relation I
suggest to standardize a field F in MAINTAINERS that specifies the
associated files. (There are already three entries that have such a
field.) I'm not sure if the content should be a regular expression or
simply a list of files/directories. The following arguments come to my
mind:
- RE usually shorter (e.g. include/linux/netfilter.* substitutes
11 files and directories).
- list of files easier readable for humans.
- list of files is more conceivable, e.g. you can pass each item to
git-log.
Moreover I suggest to mark the introduction in MAINTAINERS with '#' to
ease parsing it. (This is easy, I will reply with a patch.)
For in-file specification of maintainership I suggest similar to
MAINTAINERS:
$TOPIC
P: Joe H. Acker <joehacker@mail.do.main>
L: linux-kernel@vger.kernel.org
in the first comment of the file. (Supporting C-Style and #-comments.
Is ...
