Proposal for better attribution structure

["Eric S. Raymond" <esr@thyrsus.com>]

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