On Wednesday, 15 August 2007 04:51, Kyle Moffett wrote: > On Aug 14, 2007, at 19:24:30, Dave Jones wrote: > > On Tue, Aug 14, 2007 at 11:22:37AM -0700, Andrew Morton wrote: > >> On Tue, 14 Aug 2007 11:15:41 -0700 (PDT) Linus Torvalds > >> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > >>> In other words, it would be much better to just have per-file > >>> markers, along with some per-subdirectory stuff or similar. > >> > >> And a `make maintainers' target to pull it all together.. > >> > >> (perhaps we could add a > >> > >> maintainer <keyword> > >> > >> record to Kconfig, then `make maintainers' goes and looks up > >> <keyword> somewhere and does something with it) > > > > Not everything that's in MAINTAINERS has a Kconfig entry though, so > > it really needs to live in the .c/.h files. > > How about making "MAINTAINERS" operate vaguely similar > to .gitignore? You would need 4 pieces > > (a) A set of "Maintainers" files sprinkled around the source tree > where they make sense. Any file references would be done using > relative paths and patterns. For example, there would be one in the > root directory which has: > > [EVERYTHING ELSE] > P: Various Linux Kernel Developers > L: linux-kernel@xxxxxxxxxxxxxxx > F: * > > > Then (using the earlier SUSPEND TO RAM example) in the kernel/power/ > Maintainers file, you would have: > > [SUSPEND TO RAM] > P: Pavel Machek > M: pavel@xxxxxxx > P: Rafael J. Wysocki > M: rjw@xxxxxxx > L: linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > S: Maintained > F: * > > > Now that at least *one* of the maintainers files has the info for > Pavel and Rafael, you could just use this simpler form in any other > Maintainers file and still have it find their entries: > > [SUSPEND TO RAM] > F: linux/suspend.h > F: linux/freezer.h > F: linux/pm.h > F: asm-*/suspend.h > > > (b) You would need a little tool which generates a combined > MAINTAINERS file when "make maintainers" is run. It would iterate > over the directory tree and combine entries with the same names. > This also allows you to group people with their associated files even > if they work on the same subsystem/driver; they would be listed in > the respective sub-Maintainer-files, but when built it would mention > both of them. The intent would not be a MAINTAINERS file which is > perfectly human-readable, it would be one which can be efficiently > grepped by a helper tool to find the necessary information. When the > resulting MAINTAINERS file is built it would include the source > "Maintainers" file for each chunk right before said chunk, for example: > > [SUSPEND TO RAM] > > Origin: kernel/power/Maintainers > P: Pavel Machek > M: pavel@xxxxxxx > P: Rafael J. Wysocki > M: rjw@xxxxxxx > L: linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > S: Maintained > F: kernel/power/* > > Origin: include/Maintainers > F: include/linux/suspend.h > F: include/linux/freezer.h > F: include/linux/pm.h > F: include/asm-*/suspend.h > > > > (c) You would need a tool to go digging through the built > MAINTAINERS file based on a file, an email address, a subsystem-name- > regexp, etc. It would return all matching entries, with the desired > fields user-selectable. > > > (d) You would need a little tool to poke at git similar to the shell > script Linus posted which dug through the recent commit history > looking for people doing significant *original* modifications (IE: > first person to sign-off) on code for which they aren't a maintainer, > as well as "Maintainers" who haven't recently signed off at all on > code for which they are responsible. The output might be something > like this: > > > ## Historical significance: 6 months > > ## Uncategorized file threshold: >10 changes or >20 sign-offs > > ## New maintainer threshold: >20 changes or >40 sign-offs > > ## Neglectful-maintainer threshold: <5 changes and <10 sign-offs > > > > [SUSPEND TO RAM] > > Nigel Cunningham should probably be a maintainer: > > kernel/power/* (130 changes, 132 sign-offs) > > include/linux/suspend.h (29 changes, 29 sign-offs) > > > > [RANDOM UNMAINTAINED DRIVER] > > J. Random Hacker has neglected his maintainership: > > drivers/random/unmaintained.c (0 changes, 0 sign-offs) > > > > [UNCATEGORIZED] > > John Linville should probably add/update a Maintainers entry: > > drivers/wireless/newly_added_driver.c (142 changes and 453 sign- > > offs) I like this idea. :-) Greetings, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
