linux-kernel - [RFC] How to (automatically) find the correct maintainer(s)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 13 Jan 2007 17:30:39 +0100
From:	Richard Knutsson <ricknu-0@...dent.ltu.se>
To:	linux-kernel@...r.kernel.org
Subject: [RFC] How to (automatically) find the correct maintainer(s)

Hello all

Would like to come with a suggestion I have been wondering about for a 
while, why not add the config-flag, used in Kconfig/Makefile in the 
MAINTAINERS-file?

By doing this, there would not be any confusion who to send a patch, 
since all "files" is defined under a flag, right? (when it is a 
header-file, it can be grep'ed on the c-files and from the hit find the 
flag)

So, with a MAINTAINERS-entry like:

SUPERCOOL ALPHA CARD

P:	Clark Kent
M:	superman@...pton.kr
L:	some@...ng.com
C:	SUPER_A
S:	Maintained
(C: for CONFIG. Any better idea?)

then if someone changes a file who are built with CONFIG_SUPER_A, can 
easily backtrack it to the correct maintainer(s). And because there is 
no question how to find the correct maintainer, a script can do it for 
us. This is something that would be really useful for Kernel-Janitors 
when doing big cleanups all over the kernel (see ex pci_module_init to 
pci_register_driver and standardize the tree to use macros from 
include/linux/kernel.h).
By this, I believe trivial patch-series would be reduced from the lkml 
when they can automatically be sent to the maintainer (and maybe 
specified mailing-list).

My first idea was to use the pathway and define that directories above 
the specified (if not specified by another) would fall to the current 
maintainer. It would work, but requires that all pathways be specified 
at once, or a few maintainers with "short" pathways would get much of 
the patches (and it is not as correct/easy to maintain as looking for 
the CONFIG_flag).

Any thoughts on this is very much appreciated (is there any flaws with 
this?).

Richard Knutsson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/