[RFC] List of maintainers (draft #3)

[RFC] List of maintainers (draft #3)

[Denis Vlasenko]

After recent discussion on Linux development practices I think it may be
worthy to have list of lk maintainers. Unlike one included into kernel
source, this document is meant to be monthly (weekly?) mailed to lkml
and to be modified whenever new victim wishes to be listed in it
or someone can no longer devote his time to maintainer work.

This is a third draft. I picked some names and addresses and made entried for 
them. If you want to be in this list, mail me your corrected entry.

Please indicate what kind of reports you wish to receive and what kind of 
reports you DON'T want to see.

I want these entries to sound like "Hey, I am working on these parts of the
kernel, if you have something, send it to me not to Linus". With precise
indication of those parts and your level of involvement:

If you don't want to be in this list, mail me too - I'll remove your entry.

Note that English isn't my native language, feel free to correct any mistakes.
--
vda

* * * * DRAFT * * * *

So, you are new to Linux kernel hacking and want to submit a kernel bug
report or a patch but don't know how to do it and _where_ to report it?

Preparing bug report:
=====================
Oops: decode it with ksymoops
Unkillable process: Alt-SysRq-T and ksymoops relevant part
* Yes it means you should have ksymoops installed and tested!
* More info in the FAQ at http://www.tux.org/lkml/

Sending bug report/patch:
=========================
* It never hurts to send to Linux kernel mailing list.
* Some device drivers have active developers, try to contact them first.
* Otherwise find a subsystem maintainer to which your report pertains
  and send report to his address.
* Small fixes and device driver updates are best directed to subsystem
  maintainers and "small bits" integrators.
* Do not send it to all addresses at once! This will annoy lots of people
  and isn't useful at all.
* Do NOT send it to Linus.
* If your patch is something big and new, announce it on lkml and try
  to attract testers. After it has been tested and discussed, you can
  expect Linus to consider inclusion in mainline.

Note that this list is sorted in reversed date order, most recent
entries first. This means than entries at bottom can be outdated :-(


		Current Linux kernel people

Linux kernel mailing list <linux-kernel@vger.kernel.org>
	Post anything related to Linux kernel here, but nothing else :-)

Geert Uytterhoeven <geert@linux-m68k.org> [07 feb 2002]
	I work on the frame buffer subsystem, the m68k port (Amiga part),
	and the PPC port (CHRP LongTrail part).
	Unfortunately I barely have spare time to really work on these
	things. My job is not Linux-related (so far :-). I can not
	promise anything about my maintainership performance.

H. Peter Anvin <hpa@zytor.com> [07 feb 2002]
        i386 boot and feature code, i386 boot protocol, autofs3,
        compressed iso9660 (but I'll accept all iso9660-related
        changes.)  kernel.org site manager; please contact me
        for sponsorship-related issues.

kernel.org admins <ftpadmin@kernel.org> [07 feb 2002]
	Kernel.org sysadmins.  Contact us if you notice something breaks,
	or if you want a change make sure you give us at least 1-2 weeks.
	Please note that we got a lot of feature requests, a lot of
	which conflict or simply aren't practical; we don't have time to
	respond to all requests.

Greg KH <greg@kroah.com> [07 feb 2002]
	I am USB and PCI Hotplug maintainer.

Trond Myklebust <trond.myklebust@fys.uio.no> [07 feb 2002]
	I am NFS client maintainer.

James Simmons <jsimmons@transvirtual.com> [07 feb 2002]
	Console and framebuffer sybsustems.
	I also play around with the input layer.

Richard Gooch <rgooch@atnf.csiro.au> [07 feb 2002]
	I maintain devfs.  I want people to Cc: me when reporting devfs
	problems, since I don't read all messages on linux-kernel.
	Send devfs related patches to me directly, rather than
	bypassing me and sending to Linus/Marcelo/Alan/Dave etc.

Russell King <rmk@arm.linux.org.uk> [06 feb 2002]
	ARM architecture maintainer.  Please send all ARM patches through
	the patch system at http://www.arm.linux.org.uk/developer/patches/
	New serial drivers maintainer for 2.5.  Submit patches to
	rmk+serial@arm.linux.org.uk

Andrew Morton <akpm@zip.com.au> [05 feb 2002]
	I'm receptive to any reproducible bug anywhere in the 2.4 kernel.
	Specialising in ext2, ext3 and network drivers.
	Not thinking about 2.5.x at this time.

Petr Vandrovec <vandrove@vc.cvut.cz> [05 feb 2002]
	ncpfs filesystem, matrox framebuffer driver, problems related
	to VMware - in all of 2.2.x, 2.4.x and 2.5.x.

Reiserfs developers list <reiserfs-dev@namesys.com> [05 feb 2002]
	Send all reiserfs-related stuff here including but not limited to bug
	reports, fixes, suggestions.

Oleg Drokin <green@linuxhacker.ru> [05 feb 2002]
	SA11x0 USB-ethernet and SA11x0 watchdog are mine.

Vojtech Pavlik <vojtech@ucw.cz> [05 feb 2002]
	Feel free to send me bug reports and patches to input device drivers
	(drivers/input/*, drivers/char/joystick/*)
	I also want to receive bug reports and patches for following
	USB drivers: printer, acm, catc, hid*, usbmouse, usbkbd, wacom.
	All other (not in the list) USB driver changes should go to USB
	maintainer (hopefully there is one listed here :-).
	Also CC me if you are posting VIA IDE driver related message
	(although I am not IDE subsystem maintainer).

======= These entries are suggested by lkml folks ========

David S. Miller <davem@redhat.com> [07 feb 2002]
	I am Sparc64 and networking core maintainer.

======= These ones I made myself ========
======= I am waiting confirmation from these people ========

Alan Cox <alan@lxorguk.ukuu.org.uk> [5 feb 2002]
	I am 2.2 maintainer.
	I collect various bits and pieces for inclusion in 2.4.
	You may send unmaintained driver fixes/updates to me.

Alexander Viro <viro@math.psu.edu> [5 feb 2002]
	I am NOT a fs subsystem maintainer. But I won't kill
	you if you send me some generic fs bug reports and (hopefully) patches.

Andre Hedrick <andre@linux-ide.org> [5 feb 2002]
	I am IDE guy.

Andrea Arcangeli <andrea@suse.de> [5 feb 2002]
	Send VM related bug reports and patches to me.

Arnaldo Carvalho de Melo <acme@conectiva.com.br> [5 feb 2002]
	?

Dave Jones <davej@suse.de> [5 feb 2002]
	I collect various bits and pieces for inclusion in 2.5,
	espesially small and trivial ones and driver updates. Do not bother
	Linus with them. I'll feed them to Linus when (and if) they
	are proved to be worthy.

Eric S. Raymond <esr@thyrsus.com> [5 feb 2002]
	Send kernel configuration bug reports and suggestions to me.
	Also I'll be more than happy to accept help enties for kernel config
	options for Configure.help.

GИrard Roudier <groudier@free.fr> [5 feb 2002]
	I am SCSI guy.

Hans Reiser <reiser@namesys.com> [5 feb 2002]
	ReiserFS is my favorite toy.

Ingo Molnar <mingo@elte.hu> [5 feb 2002]
	New scheduler in 2.5 and Tux are mine.

Jeff Garzik <jgarzik@mandrakesoft.com> [5 feb 2002]
	?

Jens Axboe <axboe@suse.de> [5 feb 2002]
	I am block device subsystem maintainer.

Keith Owens <kaos@ocs.com.au> [5 feb 2002]
	ksymoops, kbuild, .. .. .. .. .  are mine.

Linus Torvalds <torvalds@transmeta.com> [5 feb 2002]
	Do not send anything to me unless it is for 2.5, well tested,
	discussed on lkml and is used by significant number of people.
	In general it is a bad idea to send me small fixes and driver
	updates, send them to subsystem maintainers and/or
	"small stuff" integrator (currently Dave Jones, see his entry)
	Sorry, I can't do everything.

Marcelo Tosatti <marcelo@conectiva.com.br> [5 feb 2002]
	Do not send anything to me unless it is for 2.4 and well tested.
	If you are sending me small fixes and driver updates, send
	a copy to subsystem maintainers and/or "small stuff" integrator
	(currently Alan Cox, see his entry).

Rik van Riel <riel@conectiva.com.br> [5 feb 2002]
	Send me VM related stuff.

Robert Love <rml@tech9.net> [5 feb 2002]
	Preemptible kernel is mine.

Rusty Russell <rusty@rustcorp.com.au> [5 feb 2002]
	?

Re: [RFC] List of maintainers (draft #3)

[Uwe Kleine-König]

On Thu, Feb 07, 2002 at 12:54:56PM -0200, Denis Vlasenko wrote:
> After recent discussion on Linux development practices I think it may be
> worthy to have list of lk maintainers. Unlike one included into kernel
> source, this document is meant to be monthly (weekly?) mailed to lkml
> and to be modified whenever new victim wishes to be listed in it
> or someone can no longer devote his time to maintainer work.
I don't see an advantage of a regular mail compared to a file in the
tree, but obviously YMMV.

But another thing really bothers me:  I think there should not be more
than one place I have to look up manually for maintainers.  Currently I
have ~100 easy patches pending and the most time consuming part of
finishing these is looking up the right address to send to send them to.
Currently I already have to check the modified files for a maintainer
entry, MAINTAINERS and the history of the files.

IMHO this could be automated with some effort.  I currently imagine:
 - a MAINTAINERS maintainer?!
 - a certain format to specify a maintainer of a single file in that
   file (e.g. in a specially marked comment) to prevent overloading
   MAINTAINERS
 - maybe a per-directory .maintainers file.
 - add a field to each entry in MAINTAINERS specifying a regular
   expression or shell wildcard of the corresponding files and
   directories.
 - a script that takes a patch and extracts the addresses from the above
   sources (and optionally calls git send-email)
 
If you want to do that with an externally maintained source thats OK for
me, too, provided it eases patch submission.

Best regards
Uwe

Re: [RFC] List of maintainers (draft #3)

[Ben Dooks]

On Mon, Sep 22, 2008 at 10:12:39AM +0200, Uwe Kleine-K?nig wrote:
> On Thu, Feb 07, 2002 at 12:54:56PM -0200, Denis Vlasenko wrote:
> > After recent discussion on Linux development practices I think it may be
> > worthy to have list of lk maintainers. Unlike one included into kernel
> > source, this document is meant to be monthly (weekly?) mailed to lkml
> > and to be modified whenever new victim wishes to be listed in it
> > or someone can no longer devote his time to maintainer work.
> I don't see an advantage of a regular mail compared to a file in the
> tree, but obviously YMMV.
> 
> But another thing really bothers me:  I think there should not be more
> than one place I have to look up manually for maintainers.  Currently I
> have ~100 easy patches pending and the most time consuming part of
> finishing these is looking up the right address to send to send them to.
> Currently I already have to check the modified files for a maintainer
> entry, MAINTAINERS and the history of the files.
> 
> IMHO this could be automated with some effort.  I currently imagine:
>  - a MAINTAINERS maintainer?!
>  - a certain format to specify a maintainer of a single file in that
>    file (e.g. in a specially marked comment) to prevent overloading
>    MAINTAINERS
>  - maybe a per-directory .maintainers file.

I was thinking of at least making MAINTAINERS per-subsystem, it is a
large file and would be easier for the people submitting patcehs to
avoid having to touch a common file.

>  - add a field to each entry in MAINTAINERS specifying a regular
>    expression or shell wildcard of the corresponding files and
>    directories.
>  - a script that takes a patch and extracts the addresses from the above
>    sources (and optionally calls git send-email)

I think that is also a good idea.
  
> If you want to do that with an externally maintained source thats OK for
> me, too, provided it eases patch submission.
> 
> Best regards
> Uwe
> --
> 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/

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: [RFC] List of maintainers (draft #3)

[Pekka Enberg]

Hi,

On Mon, Sep 22, 2008 at 12:12 PM, Ben Dooks <ben-linux@fluff.org> wrote:
> I was thinking of at least making MAINTAINERS per-subsystem, it is a
> large file and would be easier for the people submitting patcehs to
> avoid having to touch a common file.

Figuring out whom to send a patch to is not something you can automate
because it not only depends on what you're changing but *how* you're
changing it. The classic case being that whenever you change something
related to RCU that's non-trivial, you almost certainly want to CC
Paul "RCU" McKenney. But there's no *file* or *directory* pattern that
can automatically tell you this.

Furthermore, if you're hacking on a specific part of the kernel, you
almost certainly are doing it wrong if you don't know who the relevant
maintainers are. For simple janitorial patches, you probably should
just work out the *top-level* maintainers (davem for networking, ingo
et al for x86, and so on) and send the patches to them. And when these
simple rules fail you, fall back to patch bombing Andrew.

                             Pekka

Re: [RFC] List of maintainers (draft #3)

[H. Peter Anvin]

Pekka Enberg wrote:
> 
> Figuring out whom to send a patch to is not something you can automate
> because it not only depends on what you're changing but *how* you're
> changing it. The classic case being that whenever you change something
> related to RCU that's non-trivial, you almost certainly want to CC
> Paul "RCU" McKenney. But there's no *file* or *directory* pattern that
> can automatically tell you this.
> 
> Furthermore, if you're hacking on a specific part of the kernel, you
> almost certainly are doing it wrong if you don't know who the relevant
> maintainers are. For simple janitorial patches, you probably should
> just work out the *top-level* maintainers (davem for networking, ingo
> et al for x86, and so on) and send the patches to them. And when these
> simple rules fail you, fall back to patch bombing Andrew.
> 

This is, of course, true; however, there are people who should *always* 
be included when touching specific files, and this *can* be automated. 
This is particularly so when sending out cross-architectural patchsets.

So no, automation isn't a substitute for intelligence, but that doesn't 
mean that it can't be an *assistance*.

We need this.  Right now too many people screw up even the part that 
*can* be automated.

	-hpa

Re: [RFC] List of maintainers (draft #3)

[Uwe Kleine-König]

Hello,

(hhm, my MTA failed to send my mail to Denis.  I'll try once more.)

On Mon, Sep 22, 2008 at 09:40:02AM -0700, H. Peter Anvin wrote:
> Pekka Enberg wrote:
>> Figuring out whom to send a patch to is not something you can automate
>> because it not only depends on what you're changing but *how* you're
>> changing it. The classic case being that whenever you change something
>> related to RCU that's non-trivial, you almost certainly want to CC
>> Paul "RCU" McKenney. But there's no *file* or *directory* pattern that
>> can automatically tell you this.
>> Furthermore, if you're hacking on a specific part of the kernel, you
>> almost certainly are doing it wrong if you don't know who the relevant
>> maintainers are. For simple janitorial patches, you probably should
>> just work out the *top-level* maintainers (davem for networking, ingo
>> et al for x86, and so on) and send the patches to them. And when these
>> simple rules fail you, fall back to patch bombing Andrew.
>
> This is, of course, true; however, there are people who should *always* be 
> included when touching specific files, and this *can* be automated. This is 
> particularly so when sending out cross-architectural patchsets.
>
> So no, automation isn't a substitute for intelligence, but that doesn't 
> mean that it can't be an *assistance*.
>
> We need this.  Right now too many people screw up even the part that *can* 
> be automated.
Thanks hpa.  That would have been roughly my response, too.  I can see
Pekka's point, too, but IMHO the advantages outweight the disadvantages.
This might result in some mails that don't reach the complete needed
audience, but it should assert that at least one right person is reached
and this one probably knows who to forward the mail.  I expect that in
most cases the automatic answer is right, though.

Continuing planning how to implement such an automation I found that
git-send-email already has an option --cc-cmd=/path/to/some/program.
program is called once per patch and should print email addresses to
stdout.  (This is already nearly optimal.  The only missing part is that
the addresses should occur in the resulting commit in a Cc: line.  This
could be implemented in program, too, but for me it feels wrong to do it
there.  IMHO git-send-email would be the better place.  I consider this
lower prio, though, so this has to wait (or be done by someone else).)

To go forward with how to specify a file <-> maintainer relation I
suggest to standardize a field F in MAINTAINERS that specifies the
associated files.  (There are already three entries that have such a
field.)  I'm not sure if the content should be a regular expression or
simply a list of files/directories.  The following arguments come to my
mind:
  - RE usually shorter (e.g. include/linux/netfilter.* substitutes
    11 files and directories).
  - list of files easier readable for humans.
  - list of files is more conceivable, e.g. you can pass each item to
    git-log.
Moreover I suggest to mark the introduction in MAINTAINERS with '#' to
ease parsing it.  (This is easy, I will reply with a patch.)

For in-file specification of maintainership I suggest similar to
MAINTAINERS:

	$TOPIC
	P: Joe H. Acker <joehacker@mail.do.main>
	L: linux-kernel@vger.kernel.org

in the first comment of the file.  (Supporting C-Style and #-comments.
Is anything more needed?)

I will start experimenting a bit and hope to provide some results soon.

I look forward to any constructive feedback.

Best regards
Uwe

Re: [RFC] List of maintainers (draft #3)

[Joe Perches]

On Mon, 2008-09-22 at 21:42 +0200, Uwe Kleine-König wrote:
> Continuing planning how to implement such an automation I found that
> git-send-email already has an option --cc-cmd=/path/to/some/program

I added cc-cmd to git-send-email.

> To go forward with how to specify a file <-> maintainer relation I
> suggest to standardize a field F in MAINTAINERS that specifies the
> associated files.

I did roughly the same thing last year with MAINTAINERS entries
and a script for patch submission.

http://lkml.org/lkml/2007/8/13/17

There were a few iterations before Linus said he didn't much
like the idea.

http://lkml.org/lkml/2007/8/13/1139

I still think it's useful and don't think a particularly
better way exists to generate this information.

I think the best way to manage this content is to separate
the monolithic MAINTAINERS into separate Maintainers/subsection
files (which would be automatically alphabetized) and to create
an aggregated MAINTAINERS file via Makefile.

If per directory .maintainers files are created, there'll
be roughly the same number of files.

http://lkml.org/lkml/2007/8/17/119

cheers, Joe

Re: [RFC] List of maintainers (draft #3)

[Pavel Machek]

Hi!

>> Figuring out whom to send a patch to is not something you can automate
>> because it not only depends on what you're changing but *how* you're
>> changing it. The classic case being that whenever you change something
>> related to RCU that's non-trivial, you almost certainly want to CC
>> Paul "RCU" McKenney. But there's no *file* or *directory* pattern that
>> can automatically tell you this.
>>
>> Furthermore, if you're hacking on a specific part of the kernel, you
>> almost certainly are doing it wrong if you don't know who the relevant
>> maintainers are. For simple janitorial patches, you probably should
>> just work out the *top-level* maintainers (davem for networking, ingo
>> et al for x86, and so on) and send the patches to them. And when these
>> simple rules fail you, fall back to patch bombing Andrew.
>>
>
> This is, of course, true; however, there are people who should *always*  
> be included when touching specific files, and this *can* be automated.  
> This is particularly so when sending out cross-architectural patchsets.
>
> So no, automation isn't a substitute for intelligence, but that doesn't  
> mean that it can't be an *assistance*.
>
> We need this.  Right now too many people screw up even the part that  
> *can* be automated.

Yes please. Manually searching MAINTAINERS is  boring and hard... 'Is
it NETWORK BLOCK DEVICE' or 'NBD'? 'ALSA' or 'ADVANCED LINUX SOUND 
SYSTEM'? ... plus if you want subsystem maintainer, search tends to
give you about 179 individual driver maintainers, first.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC] List of maintainers (draft #3)

[Joe Perches]

On Tue, 2008-09-30 at 17:10 -0700, Randy Dunlap wrote:
> On Mon, 29 Sep 2008 19:56:25 +0200 Pavel Machek wrote:
> > Yes please. Manually searching MAINTAINERS is  boring and hard... 'Is
> > it NETWORK BLOCK DEVICE' or 'NBD'? 'ALSA' or 'ADVANCED LINUX SOUND 
> > SYSTEM'? ... plus if you want subsystem maintainer, search tends to
> > give you about 179 individual driver maintainers, first.
> Well.... both the acronym and long name should be listed IMO.
> Especially the acronym/short name.

Human based visual searches are error prone.

There really does need to be some systematic and automated
mechanism to find the maintainers for a particular file.

Maintainer file patterns, either centralized in MAINTAINERS
or distributed in some mechanism in the file system or git
are useful.

Linus' original point about "hotness" of MAINTAINERS being
an issue was later refuted by Linus.

http://lkml.org/lkml/2008/2/13/414

Re: [RFC] List of maintainers (draft #3)

[Randy Dunlap]

On Mon, 29 Sep 2008 19:56:25 +0200 Pavel Machek wrote:

> Yes please. Manually searching MAINTAINERS is  boring and hard... 'Is
> it NETWORK BLOCK DEVICE' or 'NBD'? 'ALSA' or 'ADVANCED LINUX SOUND 
> SYSTEM'? ... plus if you want subsystem maintainer, search tends to
> give you about 179 individual driver maintainers, first.

Well.... both the acronym and long name should be listed IMO.
Especially the acronym/short name.

---
~Randy

Re: [RFC] List of maintainers (draft #3)

[Randy Dunlap]

On Tue, 30 Sep 2008 17:09:50 -0700 Joe Perches wrote:

> On Tue, 2008-09-30 at 17:10 -0700, Randy Dunlap wrote:
> > On Mon, 29 Sep 2008 19:56:25 +0200 Pavel Machek wrote:
> > > Yes please. Manually searching MAINTAINERS is  boring and hard... 'Is
> > > it NETWORK BLOCK DEVICE' or 'NBD'? 'ALSA' or 'ADVANCED LINUX SOUND 
> > > SYSTEM'? ... plus if you want subsystem maintainer, search tends to
> > > give you about 179 individual driver maintainers, first.
> > Well.... both the acronym and long name should be listed IMO.
> > Especially the acronym/short name.
> 
> Human based visual searches are error prone.
> 
> There really does need to be some systematic and automated
> mechanism to find the maintainers for a particular file.
> 
> Maintainer file patterns, either centralized in MAINTAINERS
> or distributed in some mechanism in the file system or git
> are useful.
> 
> Linus' original point about "hotness" of MAINTAINERS being
> an issue was later refuted by Linus.
> 
> http://lkml.org/lkml/2008/2/13/414

I just don't think that it's a big problem like you and Pavel seem to.
IOW I'll just disagree.

---
~Randy

[PATCH] [RFC] Add a script that searched per-file maintainers for a patch.

[Uwe Kleine-König]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4246 bytes --]

I assume currently there are no files that have the maintainers noted in
a source file in a way that is understandable by the script, but for
testing you can use scripts/genpatchcc.py itself.  It is meant to be
used with git-send-email --cc-cmd=...

Currently the format to specify a maintainer is

	/*
	 * TOPIC
	 * P: M. Aintainer <ma@intai.ner>
	 * L: some-list@vger.kernel.org
	 */

similar to the format of the MAINTAINERS file.  This has to be specified
in the first comment of a file starting at the file's start.  #-like
comments are supported, too.

---
To test it, apply the patch, and modify scripts/genpatchcc.py.  Then you
can run:

	git diff | scripts/genpatchcc.py

I havn't tested it yet with git-send-email and there are several things
to improve as noted in the comments of the script (and probably more).
And of course some documentation is missing.

Please consider it as a first draft and feel free to comment.

Best regards
Uwe
---
 scripts/genpatchcc.py |   95 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 95 insertions(+), 0 deletions(-)
 create mode 100755 scripts/genpatchcc.py

diff --git a/scripts/genpatchcc.py b/scripts/genpatchcc.py
new file mode 100755
index 0000000..6a757ed
--- /dev/null
+++ b/scripts/genpatchcc.py
@@ -0,0 +1,95 @@
+#! /usr/bin/env python
+# vim: set fileencoding=utf-8
+# (c) Uwe Kleine-König <ukleinek@strlen.de>
+# GPLv2
+#
+# GENPATCHCC
+# P: Uwe Kleine-König <ukleinek@strlen.de>
+
+# wishlist:
+# - support for per-directory '.maintainers' file
+#   when should it be used?  Assume a/b/c/d/file was changed.  The following
+#   files could be used:
+#    * a/b/c/d/.maintainers
+#    * a/b/c/.maintainers
+#    * a/b/.maintainers
+#    * a/.maintainers
+#    * .maintainers
+#   maybe only use the first that exists?  only if the changed file doesn't
+#   have an entry?
+# - (?) option to specify the srcdir
+# - (?) parse the patch if the maintainer entry is changed, use both, old and new version
+# - (?) extract git sha1 sums and parse the objects
+
+import fileinput
+import re
+
+def filename(name):
+    if name[0] == '"':
+        raise NotImplementedError, 'please teach me how to unquote a filename'
+
+    # assume -p1
+    return name[name.index('/') + 1:]
+
+re_changedfile = re.compile(r'(?:---|\+\+\+)\s(?P<file>".*?[^\\]"|[][-^A-Za-z0-9_ !#$%&\'()*+,./:;<=>@?{}~]+)')
+
+changed_files = set()
+
+for line in fileinput.input():
+    mo = re_changedfile.match(line)
+    if mo:
+        changed_files.add(filename(mo.group('file')))
+
+def extract_maintainers(file, compre_dict, dowhile=None):
+    next = ('start', 'topic')
+    anyfield = ('person', 'ml', 'otherfield')
+    next_dict = dict(start=('topic',), topic=anyfield, person=anyfield, ml=anyfield, otherfield=anyfield)
+
+    for line in file:
+        if dowhile is not None:
+            mo = dowhile.match(line)
+            if not mo:
+                break
+
+        for possnext in next:
+            mo = compre_dict[possnext].match(line)
+            if mo:
+                for v in mo.groupdict().itervalues():
+                    print v
+                next = next_dict[possnext]
+                break
+        else:
+            mo = compre_dict['start'].match(line)
+            if mo:
+                next = next_dict['start']
+            else:
+                next = ('start',)
+
+re_dict = dict(start=r'$',
+        topic=r'\S[^:].*',
+        person=r'P:\s*(?P<person>.*)',
+        ml=r'L:\s*(?P<ml>.*)',
+        otherfield=r'(?![PL])[A-Z]:')
+
+re_comment = r'\s*(?:#|/?\*)'
+
+compre_dict = dict((key, re.compile(value)) for key, value in re_dict.iteritems())
+compre_commented_dict = dict((key, re.compile(re_comment + r'\s*' + value)) for key, value in re_dict.iteritems())
+compre_comment = re.compile(re_comment)
+
+mailto_person = set()
+mailto_ml = set()
+
+for file in changed_files:
+    # MAINTAINERS [cw]ould result in many false matches, skip it
+    # alternatively print someone?  who?
+    if file == 'MAINTAINERS':
+        continue
+
+    try:
+        of = open(file)
+    except:
+        # TODO: try harder (e.g. is the patch really -p1?)
+        continue
+
+    extract_maintainers(of, compre_commented_dict, compre_comment)
-- 
1.5.6.5

Re: [RFC] List of maintainers (draft #3)

[Pavel Machek]

On Tue 2008-09-30 17:35:12, Randy Dunlap wrote:
> On Tue, 30 Sep 2008 17:09:50 -0700 Joe Perches wrote:
> 
> > On Tue, 2008-09-30 at 17:10 -0700, Randy Dunlap wrote:
> > > On Mon, 29 Sep 2008 19:56:25 +0200 Pavel Machek wrote:
> > > > Yes please. Manually searching MAINTAINERS is  boring and hard... 'Is
> > > > it NETWORK BLOCK DEVICE' or 'NBD'? 'ALSA' or 'ADVANCED LINUX SOUND 
> > > > SYSTEM'? ... plus if you want subsystem maintainer, search tends to
> > > > give you about 179 individual driver maintainers, first.
> > > Well.... both the acronym and long name should be listed IMO.
> > > Especially the acronym/short name.
> > 
> > Human based visual searches are error prone.
> > 
> > There really does need to be some systematic and automated
> > mechanism to find the maintainers for a particular file.
> > 
> > Maintainer file patterns, either centralized in MAINTAINERS
> > or distributed in some mechanism in the file system or git
> > are useful.
> > 
> > Linus' original point about "hotness" of MAINTAINERS being
> > an issue was later refuted by Linus.
> > 
> > http://lkml.org/lkml/2008/2/13/414
> 
> I just don't think that it's a big problem like you and Pavel seem to.
> IOW I'll just disagree.

Quickly, check who's maintainer of ALSA.

...shall we add rule that subsystems will have "subsystem" in the name
so that search does not list all the drivers, first?

Signed-off-by: Pavel Machek <pavel@suse.cz>

diff --git a/MAINTAINERS b/MAINTAINERS
index 3596d17..7345707 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3825,7 +3825,7 @@ L:	linux-kernel@vger.kernel.org
 W:	http://tifmxx.berlios.de/
 S:	Maintained
 
-SOUND
+SOUND SUBSYSTEM (ADVANCED LINUX SOUND SYSTEM, ALSA)
 P:	Jaroslav Kysela
 M:	perex@perex.cz
 L:	alsa-devel@alsa-project.org (subscribers-only)
@@ -3855,7 +3855,7 @@ L:	cbe-oss-dev@ozlabs.org
 W:	http://www.ibm.com/developerworks/power/cell/
 S:	Supported
 
-STABLE BRANCH:
+STABLE BRANCH
 P:	Greg Kroah-Hartman
 M:	greg@kroah.com
 P:	Chris Wright


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC] List of maintainers (draft #3)

[Randy Dunlap]

On Wed, 1 Oct 2008 15:36:08 +0200 Pavel Machek wrote:

> ...shall we add rule that subsystems will have "subsystem" in the name
> so that search does not list all the drivers, first?

We don't have a good track record with such rules, but I don't
mind trying that.

> Signed-off-by: Pavel Machek <pavel@suse.cz>

Acked-by: Randy Dunlap <randy.dunlap@oracle.com>

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3596d17..7345707 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3825,7 +3825,7 @@ L:	linux-kernel@vger.kernel.org
>  W:	http://tifmxx.berlios.de/
>  S:	Maintained
>  
> -SOUND
> +SOUND SUBSYSTEM (ADVANCED LINUX SOUND SYSTEM, ALSA)
>  P:	Jaroslav Kysela
>  M:	perex@perex.cz
>  L:	alsa-devel@alsa-project.org (subscribers-only)
> @@ -3855,7 +3855,7 @@ L:	cbe-oss-dev@ozlabs.org
>  W:	http://www.ibm.com/developerworks/power/cell/
>  S:	Supported
>  
> -STABLE BRANCH:
> +STABLE BRANCH
>  P:	Greg Kroah-Hartman
>  M:	greg@kroah.com
>  P:	Chris Wright


I see that a few more items need their trailing ':' removed:
DISKQUOTA:
IP MASQUERADING:
IPATH DRIVER:
SUSPEND TO RAM:


Thanks.
---
~Randy