Messages in this thread | | | Date | Fri, 20 Apr 2001 20:52:46 -0400 | From | "Eric S. Raymond" <> | Subject | Proposal for better attribution structure |
| |
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/
| |