Well, in the past I had suggested to ESR (and he agreed) that it would
be nice to split up the MAINTAINERS file (and maybe even Configure.help)
to be more heirarchical in nature, so that there would be a MAINTAINER
file in each directory, and maybe even MAINTAINER.<file> for files in
common directories like drivers/net/foo.c. In the top-level MAINTAINER
file would only be something like "Marcello Tosatti" to cover the
entire tree, and e.g. "David Miller" in the net/MAINTAINER, "Al Viro" in
the fs/MAINTAINER, "Stephen Tweedie" in fs/ext3/MAINTAINER, etc.
This way the entire tree has coverage, and if a high-level maintainer gets
email for stuff that isn't relevant to them then they create a sub-MAINTAINER
file for the things they want to delegate. It could be possible to add a
keyword to the file which says "I have full authority for this tree and don't
include a higher-level maintainer in cclist output". This would mean that
for people like DaveM or arch maintainers who want ALL patches to go through
them, it would not list Marcello or Linus in the cclist. For "unmaintained"
areas (e.g. drivers) the only person listed would be the top-level maintainer,
and it would be easy for him to say "you are the first person to care about
this driver in a while, you are now the maintainer".
It might be good (for compatibility sake) to build the top-level MAINTAINERS
file from all of the sub-MAINTAINER files in the tree.
This approach doesn't have the "scalability" of the web-based subscription
model, but it _does_ have the benefit that it is kept in-sync with the tree
that it is distributed with, and it would be a simple script to determine
whom to send patches to (i.e. the proposed "cclist" script above would be
very easy to write and could be CLI only). I would think the two are
complimentary.
Cheers, Andreas
-- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/