Andreas Dilger <adilger@turbolinux.com>:
> One of the issues for contacting each MAINTAINER is that this information
> is out-of-line from the actual kernel tree. The other is that the
> description of what a maintainer is actually controlling is somewhat
> vague.
I strongly agree. I first tripped over this problem when I was trying
to identify the responsible parties for [Cc]onfig.in files. It's
biting me again now that I'm trying to clean up the CONFIG_ space.
It's one that's going to cause grief for anybody trying to do *global*
work on the kernel, stuff that crosses boundaries between maintainer
jurisdictions.
> How about the following:
> - each directory has a MAINTAINERS file which lists parties with a
> vested interest in files in that directory (format is mostly the
> same as current)
> - subdirectories which don't have a MAINTAINERS file use the MAINTAINERS
> file of the parent (or grandparent) directory
> - each maintainer entry explicitly lists each file/directory that this
> person is interested in, maybe "F: {file | directory} ...".
>
> I'm sure Eric can come up with a simple program to parse the MAINTAINER
> file/tree. If the program takes a kernel-tree relative filename and
> spit out the name/email of the relevant maintainer (subsystem and port
> specific mailing lists should also be included), that would make the
> job of finding out who to send patches to a whole lot easier.
The spirit of this proposal is, IMO, excellent. I like the idea that if
maintainer information for a particular piece of the hierarchy doesn't
exist, you float up to the next higher level. Search always ends at
the root MAINTAINERS file.
And I could indeed write a program such as Andreas describes, and would
be most willing to do so.
I have one objection, however. I think the maintainers information
should normally be inline of the file in question, so there won't
be a need for an explicit F: link that could become invalid. So I
think the search order should look like this:
1. Look for maintainer markup in the file itself.
2. Then look for a NAINTAINERS file in the current directory.
3. Then look upwards for MAINTAINERS files in enclosing directories.
> My one gripe about the MAINTAINERS file is that it still lists Remy
> Card as EXT2 maintainer, so we would probably need to do a find on
> the whole kernel tree, email each address a list of files that they
> "maintain" and wait until they complain, agree, or time out. Once
> the database is up-to-date, it simplifies the job of keeping maintainers
> (and other interested parties) in the loop.
I have until 6 May at least to work on this, if there is consensus that it's
a good idea.
-- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>Where rights secured by the Constitution are involved, there can be no rule making or legislation which would abrogate them. -- Miranda vs. Arizona, 384 US 436 p. 491 - 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/
This archive was generated by hypermail 2b29 : Mon Apr 23 2001 - 21:00:38 EST