linux-kernel - Re: tracking MAINTAINERS versus tracking SUBSYSTEMS

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-prev] [day] [month] [year] [list]

Date:	Tue, 21 Aug 2007 15:22:09 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Joe Perches <joe@...ches.com>
CC:	"Robert P. J. Day" <rpjday@...dspring.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: tracking MAINTAINERS versus tracking SUBSYSTEMS

Joe Perches wrote:
> On Mon, 2007-08-20 at 15:31 -0400, Chris Snook wrote:
>> Until I can pass a patch or source file as an argument to a script and get out 
>> the URL of the git tree it needs to go into on the path to Linus's tree, 
>> MAINTAINERS is inadequate. If I ask for the MAINTAINER info of 
>> drivers/net/atl1/atl1_main.c, I should get back myself, my co-maintainer, our 
>> sourceforge URL, our mailing list address, etc. There should also be a 
>> mechanism, either as part of MAINTAINERS or something else, that will tell me 
>> that atl1 is part of the netdev subsystem, which is discussed on 
>> netdev@...r.kernel.org, maintained by Jeff Garzik, and has the appropriate URI 
>> for the netdev GIT tree.
> 
> Finding a specific "List" or "Web" or "Tree" from a file is
> a pretty easy extension to the current get_maintainer script.
> 
> The git_maintainer script could easily be modified to take
> a filename rather than a patch file as input too.
> 
> There is no specific "parent" information in MAINTAINERS.
> Are you suggesting there should be?
> 
> Still, it's easy to use directory parentage.
> Is that good enough?

I suppose.  I was thinking initially that directory parentage alone 
wouldn't suffice, because you could be traversing upwards from a variety 
of places with a complex patch.  But now that I think about it, a patch 
should really only be going in through one git tree, no matter how many 
subsystems it might peripherally touch.  Deciding which tree really 
requires human intelligence, so there's no point trying to automate 
that.  Multiple inheritance would be... bad...

	-- Chris
-
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/