tracking MAINTAINERS versus tracking SUBSYSTEMS

tracking MAINTAINERS versus tracking SUBSYSTEMS

[Robert P. J. Day]

  this latest project of cramming the full definition of each kernel
subsystem into the MAINTAINERS file has been bothering me, and i've
finally figured out why.  it's because the MAINTAINERS file is being
asked to now be the source of reference information that just doesn't
match its name.  it's the "MAINTAINERS" file so it seems that all it
should be keeping track of is the maintainer of each subsystem, and
that's all.

  what people are clearly after is a way to match any part of the
kernel source to a subsystem and, henceforth, to a maintainer, but
there's nothing that says all of that has to be crammed into *that*
file.

  why not add a new script to the kernel source tree that, given a
file or directory name as an argument, returns its corresponding
"subsystem" that can be cross-referenced against the MAINTAINERS file?
something like:

  $ show_subsystem drivers/bluetooth/bpa10x.c
  BLUETOOTH

there would seem to be a number of advantages to this approach:

1) it reduces the MAINTAINERS file back to what it should be in the
first place -- a simple reference list of each kernel subsystem, and
who's responsible for it, so that constant reshuffling of files or
directories in a particular subsystem doesn't require constant
updating of the MAINTAINERS file.

2) you could extend the show_subsystem() routine to, once it found the
subsystem, quickly cross-reference the MAINTAINERS file and print out
the corresponding maintainer.  i believe the word "trivial" applies
here.

3) by making this a feature separate from the MAINTAINERS file, it can
be mocked up and hacked separately and finally patched in when it's
ready to go, rather than applying 5 bazillion patches to the poor
MAINTAINERS file.

4) finally, a feature like this could be used as a sanity check on the
kernel subsystem structure.  every once in a while, it could be
invoked for every single file and directory in the tree, just to see
if all of those appear to belong to at least one subsystem.  if not,
print a warning:  "Whoa, file /fubar/snafu doesn't belong to a
subsystem.  Deal with it."

  the actual implementation would seem to be easy -- perhaps a simple
text file that defines each subsystem and every file and directory
that's part of it:

FIREWIRE:drivers/firewire/,include/linux/firewire.h,... etc ...

i mean, it doesn't get a whole lot simpler than that, and it would
seem to be *way* easier to read.

  thoughts?

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: tracking MAINTAINERS versus tracking SUBSYSTEMS

[Joe Perches]

On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
>   $ show_subsystem drivers/bluetooth/bpa10x.c
>   BLUETOOTH

"what's a subsystem"?
I'm not sure there is an appropriate definition.
If there is an appropriate definition, why
should anyone care what subsystem a particular
file is in?

> 1) it reduces the MAINTAINERS file back to what it should be in the
> first place -- a simple reference list of each kernel subsystem, and
> who's responsible for it, so that constant reshuffling of files or
> directories in a particular subsystem doesn't require constant
> updating of the MAINTAINERS file.

I'd still be happy if MAINTAINERS went away.
I'm not sure what good it does other than have
a link to mailing lists that otherwise might not
be CC'd on patches.

> thoughts?

For user submission of bug reports, perhaps it'd be
more useful to have a submitkernelbugreport script
and a network enabled "dispatch bug report" to
appropriate maintainers service.

Try something out and see what happens.

Good luck.  Joe

Re: tracking MAINTAINERS versus tracking SUBSYSTEMS

[Robert P. J. Day]

On Sat, 18 Aug 2007, Joe Perches wrote:

> On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
> >   $ show_subsystem drivers/bluetooth/bpa10x.c
> >   BLUETOOTH
>
> "what's a subsystem"? I'm not sure there is an appropriate
> definition. If there is an appropriate definition, why should anyone
> care what subsystem a particular file is in?

i'm confused -- i thought that was sort of the whole purpose of this
exercise, to match parts of the kernel source tree against the
maintainer for those parts, and to do that via the defined
"subsystem" which is currently used in MAINTAINERS.

you can, of course, banish the concept of a subsystem entirely and
work purely from a file and directory perspective, but i think the
notion of the kernel tree being composed of subsystems is a useful
idea.  that's just my opinion, though.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: tracking MAINTAINERS versus tracking SUBSYSTEMS

[Joe Perches]

On Sun, 2007-08-19 at 08:22 -0400, Robert P. J. Day wrote:
> On Sat, 18 Aug 2007, Joe Perches wrote:
> > On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
> > >   $ show_subsystem drivers/bluetooth/bpa10x.c
> > >   BLUETOOTH
> > "what's a subsystem"? I'm not sure there is an appropriate
> > definition. If there is an appropriate definition, why should anyone
> > care what subsystem a particular file is in?
> i'm confused -- i thought that was sort of the whole purpose of this
> exercise, to match parts of the kernel source tree against the
> maintainer for those parts, and to do that via the defined
> "subsystem" which is currently used in MAINTAINERS.

What I did was for patch submission.

That script should probably be named "get_patch_cc_list".
It does now by default use git to find and include the
most frequent signatories.

I think that descriptions of subsystems are not
particularly useful.  The file hierarchy should
effectively do that.  I think a tool to inform a
"list of interested parties" when a file is touched
is useful though.

If there is to be a subsystem definition, I think it
needs to be hierarchical with things like specific
net drivers not a subsystem, but an element of the
subsystem net:drivers (or drivers:net or both).

If these elements are bundled together into a single
"subsystem" descriptor file you will run into the "hot"
file problem that Linus described.

cheers,  Joe

Re: tracking MAINTAINERS versus tracking SUBSYSTEMS

[Krzysztof Halasa]

"Robert P. J. Day" <rpjday@mindspring.com> writes:

> i'm confused -- i thought that was sort of the whole purpose of this
> exercise, to match parts of the kernel source tree against the
> maintainer for those parts, and to do that via the defined
> "subsystem" which is currently used in MAINTAINERS.
>
> you can, of course, banish the concept of a subsystem entirely and
> work purely from a file and directory perspective, but i think the
> notion of the kernel tree being composed of subsystems is a useful
> idea.  that's just my opinion, though.

Obviously the concept of subsystems is the right one, except that
the subsystems aren't that well defined (or they are but not
for average kernel user) - thus "file masks".
-- 
Krzysztof Halasa

Re: tracking MAINTAINERS versus tracking SUBSYSTEMS

[Chris Snook]

Joe Perches wrote:
> On Sat, 2007-08-18 at 13:35 -0400, Robert P. J. Day wrote:
>>   $ show_subsystem drivers/bluetooth/bpa10x.c
>>   BLUETOOTH
> 
> "what's a subsystem"?
> I'm not sure there is an appropriate definition.
> If there is an appropriate definition, why
> should anyone care what subsystem a particular
> file is in?

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@vger.kernel.org, maintained by Jeff Garzik, and has the appropriate URI 
for the netdev GIT tree.

	-- Chris

Re: tracking MAINTAINERS versus tracking SUBSYSTEMS

[Joe Perches]

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@vger.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?

For instance:

ATL1 has this maintainer block:

        ATL1 ETHERNET DRIVER
        P: Jay Cliburn
        M: jcliburn@gmail.com
        P: Chris Snook
        M: csnook@redhat.com
        L: atl1-devel@lists.sourceforge.net
        W: http://sourceforge.net/projects/atl1
        W: http://atl1.sourceforge.net
        S: Maintained
        F: drivers/net/atl1/
        
and NETWORK DEVICE DRIVERS has:

        NETWORK DEVICE DRIVERS
        P: Andrew Morton
        M: akpm@linux-foundation.org
        P: Jeff Garzik
        M: jgarzik@pobox.com
        L: netdev@vger.kernel.org
        T: git kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
        S: Maintained
        F: drivers/net/
        
So, NETWORK DEVICE DRIVERS would be CC'd on any change
to ATL1 (or any other driver in drivers/net/...)

Of course the same lookup could apply to L: or T:

cheers,  Joe

Re: tracking MAINTAINERS versus tracking SUBSYSTEMS

[Chris Snook]

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@vger.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