login
Search
In an overwhelmingly large series of 556 patches, Joe Perches attempted to track down maintainers for a significant number of files within the Linux kernel source tree. He explained, "I grew weary of looking up the appropriate maintainer email address(es) to CC: for a patch", adding a new line format to the kernel MAINTAINERS file parsed by a new get_maintainer.pl script.
Much of the feedback was criticism of the large number of patches that flooded the inboxes of all subscribers to the Linux Kernel Mailing List. Others suggested that the information would be better extracted from Git than from source files. When Joe asked for better ideas for achieving his end goal, Alan Cox suggested, "working off the git tree as it shows who actually is making changes/updating stuff recently and why which is a major clue when tracing bugs". Chris Wright pointed out, "I think this data will easily become stale. What is the point again?" going on to add "between git (or gitweb), existing MAINTAINERS and a bit of common sense (or extra sleuthing), I never perceived a significant problem." Adrian Bunk countered, "for active kernel developers like you and me it's not a problem. But for other people it's non-trivial to always figure out who the maintainer of some part of the kernel is."
(556 patches) From: Joe Perches [email blocked] Subject: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Sun, 12 Aug 2007 22:49:34 -0700 I grew weary of looking up the appropriate maintainer email address(es) to CC: for a patch. I added flags to the MAINTAINERS file F: file pattern for each maintained block and a script to parse the modified blocks for maintainer and list email addresses. perl scripts/get_maintainer.pl <patch> gives the appropriate maintainer(s). Modifications since last post: Added options to control email address style and multiple address separator Please apply.
From: Al Viro [email blocked] To: Joe Perches [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Mon, 13 Aug 2007 08:16:06 +0100 On Sun, Aug 12, 2007 at 10:49:34PM -0700, Joe Perches wrote: > I grew weary of looking up the appropriate > maintainer email address(es) to CC: for a patch. Does the acronym GAFL ring any bells? It's not that idea is worthless - it sure as hell is a useful thing, but what the bleeding hell is that splitup supposed to achieve? Please, people, try to think for a minute. Patch series are good not just because; there are rational reasons for that. None of those applies here; if anything, you've made sure that this patchbomb will be less reviewed. Seriously, get a fucking life. This is way past ridiculous. It does not make changes easier to test. It does not help bisect. It does not help to make changes more self-contained. It does not reduce the odds of conflict with pending patches. It does not simplify conflict resolution when porting. It does not split the change into easier understood parts. Hell, it doesn't even make it easier to revert broken parts. Use the common sense, folks. Please.
From: Sam Ravnborg [email blocked] To: Al Viro [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Mon, 13 Aug 2007 18:22:40 +0200 > > Please, people, try to think for a minute. Patch series are good not > just because; there are rational reasons for that. None of those > applies here; if anything, you've made sure that this patchbomb will > be less reviewed. This huge serie had one nice property. Relavent people got only relevant patches sent direct. They should have been sent *only* to these people and then with relevant modifications could have been applied as a single patch. Sam
From: Rene Herman [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Mon, 13 Aug 2007 19:40:10 +0200 On 08/13/2007 09:16 AM, Al Viro wrote: > On Sun, Aug 12, 2007 at 10:49:34PM -0700, Joe Perches wrote: >> I grew weary of looking up the appropriate >> maintainer email address(es) to CC: for a patch. > > Does the acronym GAFL ring any bells? It's not that idea is worthless - > it sure as hell is a useful thing, but what the bleeding hell is that > splitup supposed to achieve? Well, to be fair, he's CCing the addresses in the individual entries which is at least somewhat of a reason. Yes, could've worked via preparation via private mail as well or something but hey, posting some 600 patches is at least incredibly funny :-) Only thing left now is to now teach Linus's copy of git about these entries so that it doesn't turn into an wholy incomplete, obsolete mess through addition, removal and movement of files in a few months time... Rene.
From: "Ray Lee" [email blocked] To: "Joe Perches" [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Mon, 13 Aug 2007 10:09:08 -0700 On 8/12/07, Joe Perches [email blocked] wrote: > I grew weary of looking up the appropriate > maintainer email address(es) to CC: for a patch. > > I added flags to the MAINTAINERS file > > F: file pattern > > for each maintained block and a script to parse > the modified blocks for maintainer and list > email addresses. Why not parse git annotate or blame instead (other than it's freakin' slow)? Using the repository history has the added benefit of telling you a lot more fine-grained detail about who may want to know about your patch.
From: Adrian Bunk [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Mon, 13 Aug 2007 23:04:57 +0200 On Mon, Aug 13, 2007 at 10:09:08AM -0700, Ray Lee wrote: > On 8/12/07, Joe Perches [email blocked] wrote: > > I grew weary of looking up the appropriate > > maintainer email address(es) to CC: for a patch. > > > > I added flags to the MAINTAINERS file > > > > F: file pattern > > > > for each maintained block and a script to parse > > the modified blocks for maintainer and list > > email addresses. > > Why not parse git annotate or blame instead (other than it's freakin' > slow)? Using the repository history has the added benefit of telling > you a lot more fine-grained detail about who may want to know about > your patch. The git tree simply does not contain this information. Some of the obvious problems: - recently changed maintainership - new maintainer email address with the old one bouncing - git never contains maintainer mailing list addresses - you can't distinguish between a maintainer of a driver and people only writing or forwarding patches for a driver cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
From: Mariusz Kozlowski [email blocked] To: Joe Perches [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Mon, 13 Aug 2007 19:33:09 +0200 Hello, I don't recall discusion about this so here are my 3 cents: I like the idea. The numerous responses you got that you made a mistake and someone else is the maintainer just prove that this kind of information would be nice to have. Even if it is not going to be included in mainline it is still nice to have around as a patchset or sth. Personally I often run into trouble finding right person to CC on patches. I get the feeling that only the maintainers themselves + a few old geeks here know who is maintaining what (and which file) ;-) But maybe it's just me. The rest is as people say. These ~550 patches without 'in reply to' is a nightmare. Regards, Mariusz
From: Arjan van de Ven [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Mon, 13 Aug 2007 10:42:35 -0700 On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote: > Hello, > > I don't recall discusion about this so here are my 3 cents: > > I like the idea. I don't actually. It shows a central MAINTAINERS file is the wrong approach; just that 500+ patches to the same file were needed shows that. The maintainer info should be in the source file itself! That's the only reasonable way to keep it updated; now I'm all for having it machine parsable so that tools can use it, but it still really should be in the code itself, not in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.
From: Satyam Sharma [email blocked] To: Arjan van de Ven [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Tue, 14 Aug 2007 00:02:49 +0530 (IST) On Mon, 13 Aug 2007, Arjan van de Ven wrote: > > On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote: > > Hello, > > > > I don't recall discusion about this so here are my 3 cents: > > > > I like the idea. > > I don't actually. It shows a central MAINTAINERS file is the wrong > approach; just that 500+ patches to the same file were needed shows > that. > > The maintainer info should be in the source file itself! That's the only > reasonable way to keep it updated; now I'm all for having it machine > parsable so that tools can use it, but it still really should be in the > code itself, not in some central file that will always just go out of > data, and will be a huge source of needless patch conflicts. I second this thought (keeping MAINTAINERS info closer to code than in a central kernel-global location), but have a differing opinion about the implementation. Having MAINTAINERS-style annotations in all source files sounds needlessly redundant. Worse still, I expect people will avoid adding these annotations to all source files precisely for this reason, thus someone editing drivers/xxx/foo.c would have no idea that the maintainer info for this file is actually in drivers/xxx/bar.c. Better solution is to have multiple MAINTAINERS files distributed in the kernel tree, IMHO -- say a drivers/net/MAINTAINERS for maintainer info on all various net drivers, drivers/kvm/MAINTAINERS for KVM maintainer info, fs/ext3/MAINTAINERS for ext3 maintainers, fs/MAINTAINERS for generic VFS maintainers info, so on and so forth. Of course, these individual MAINTAINERS files could still have the newly-introduced "F:" fields as well (drivers/net/MAINTAINERS would clearly require it, f.e.) ... Satyam
From: Krzysztof Halasa [email blocked] To: Arjan van de Ven [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Mon, 13 Aug 2007 20:41:03 +0200 Arjan van de Ven [email blocked] writes: > The maintainer info should be in the source file itself! Nope, it should be outside of the (downloadable) tarball, because once someone get a tarball you can't update the data in it. This is fine WRT source (which is static given a version) but doesn't work for fast-changing data. -- Krzysztof Halasa
From: Theodore Tso [email blocked] To: Krzysztof Halasa [email blocked] Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl Date: Mon, 13 Aug 2007 16:16:30 -0400 On Mon, Aug 13, 2007 at 08:41:03PM +0200, Krzysztof Halasa wrote: > Arjan van de Ven [email blocked] writes: > > > The maintainer info should be in the source file itself! > > Nope, it should be outside of the (downloadable) tarball, because > once someone get a tarball you can't update the data in it. > This is fine WRT source (which is static given a version) but > doesn't work for fast-changing data. But the maintainers file is in the tarball today. If someone wants to take the information from the latest git tree, gather it up into a single html file, and put it on the web, more power to them. But it seems that the master source of the data should be the source file. - Ted
From: Joe Perches [email blocked] Subject: [PATCH] [2/2many] - FInd the maintainer(s) for a patch - MAINTAINERS Date: Sun, 12 Aug 2007 23:10:16 -0700 It helps when you do the diff the right way. Describe the new F: pattern Signed-off-by: Joe Perches [email blocked] diff --git a/MAINTAINERS b/MAINTAINERS index d3a0684..0d7f856 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -83,6 +83,13 @@ S: Status, one of the following: it has been replaced by a better system and you should be using that. +F: Files and directories with wildcard patterns. + A trailing slash includes all files and subdirectory files. + F: drivers/net/ all files in and below drivers/net + F: drivers/net/* all files in drivers/net, but not below + F: */net/* all files in "any top level directory"/net + One pattern per line. Multiple F: lines acceptable. + 3C359 NETWORK DRIVER P: Mike Phillips M: [email blocked]
From: Richard Knutsson [email blocked] To: Joe Perches [email blocked] Subject: Re: [PATCH] [2/2many] - FInd the maintainer(s) for a patch - MAINTAINERS Date: Mon, 13 Aug 2007 22:02:50 +0200 Joe Perches wrote: > It helps when you do the diff the right way. > > Describe the new F: pattern > > Signed-off-by: Joe Perches [email blocked] > > diff --git a/MAINTAINERS b/MAINTAINERS > index d3a0684..0d7f856 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -83,6 +83,13 @@ S: Status, one of the following: > it has been replaced by a better system and you > should be using that. > > +F: Files and directories with wildcard patterns. > + A trailing slash includes all files and subdirectory files. > + F: drivers/net/ all files in and below drivers/net > + F: drivers/net/* all files in drivers/net, but not below > + F: */net/* all files in "any top level directory"/net > + One pattern per line. Multiple F: lines acceptable. > + > 3C359 NETWORK DRIVER > P: Mike Phillips > M: [email blocked] > > Just to be clear, which one is picked with a patch for drivers/net/foo? Both or the most common one? SUBSYSTEM1 P: Person 1 F: */net/ SUBSYSTEM2 P: Person 2 F: drivers/net/ Richard "the Perl-illiterate" Knutsson
From: Joe Perches [email blocked] To: Richard Knutsson [email blocked] Subject: Re: [PATCH] [2/2many] - FInd the maintainer(s) for a patch - MAINTAINERS Date: Mon, 13 Aug 2007 13:12:40 -0700 On Mon, 2007-08-13 at 22:02 +0200, Richard Knutsson wrote: > Just to be clear, which one is picked with a patch for drivers/net/foo? > Both or the most common one? > > SUBSYSTEM1 > P: Person 1 > F: */net/ > > SUBSYSTEM2 > P: Person 2 > F: drivers/net/ Both. Find a match, add, look for more. I'm a perl "groper in the dark" myself.
From: Valdis Kletnieks [email blocked] To: Joe Perches [email blocked] Subject: Re: [PATCH] [2/2many] - FInd the maintainer(s) for a patch - MAINTAINERS Date: Mon, 13 Aug 2007 12:36:30 -0400 On Sun, 12 Aug 2007 23:10:16 PDT, Joe Perches said: > + A trailing slash includes all files and subdirectory files. > + F: drivers/net/ all files in and below drivers/net > + F: drivers/net/* all files in drivers/net, but not below Since somebody is going to screw up and do it - what are the semantics of 'drivers/net' and forgetting the trailing slash? Does your tool break on that, and if so, is it silent or noisy (if it's silent, it won't get fixed). > + F: */net/* all files in "any top level directory"/net Does the leading '*' match exactly one level, or will it match foo/bar/net/* as well? Is a construction like 'net/*/netfilter/*' legal?
From: Joe Perches [email blocked] Subject: Re: [PATCH] [2/2many] - FInd the maintainer(s) for a patch - MAINTAINERS Date: Mon, 13 Aug 2007 09:45:43 -0700 On Mon, 2007-08-13 at 12:36 -0400, Valdis.Kletnieks wrote: > On Sun, 12 Aug 2007 23:10:16 PDT, Joe Perches said: > > > + A trailing slash includes all files and subdirectory files. > > + F: drivers/net/ all files in and below drivers/net > > + F: drivers/net/* all files in drivers/net, but not below > > Since somebody is going to screw up and do it - what are the semantics > of 'drivers/net' and forgetting the trailing slash? Looks for a specific file in the patch called drivers/net > is it silent or noisy (if it's silent, it won't get fixed) silent > + F: */net/* all files in "any top level directory"/net > Does the leading '*' match exactly one level Yes > or will it match foo/bar/net/* as No match, the script counts slashes +sub file_match_pattern { + my ($file, $pattern) = @_; + if (substr($pattern, -1) eq "/") { + if ($file =~ m@^$pattern@) { + return 1; + } + } else { + if ($file =~ m@^$pattern@) { + my $s1 = ($file =~ tr@/@@); + my $s2 = ($pattern =~ tr@/@@); + if ($s1 == $s2) { + return 1; + } + } + } + return 0; +} Enhancements appreciated. > Is a construction like 'net/*/netfilter/*' legal? Yes cheers, Joe
From: Alan Cox [email blocked] To: Joe Perches [email blocked] Subject: Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT Date: Mon, 13 Aug 2007 17:35:22 +0100 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 On Mon, 13 Aug 2007 08:46:06 -0700 Joe Perches [email blocked] wrote: > On Mon, 2007-08-13 at 11:49 +0100, Alan Cox wrote: > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 90c1b81..ac2226b 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -697,6 +697,7 @@ ARPD SUPPORT > > > P: Jonathan Layes > > > L: [email blocked] > > > S: Maintained > > > +F: net/ipv4/arp.c > > > > NAK > > > > arp.c is the netdev people, ARPD is a corner case bit of code within it, > > something your patterns don't actually cope with > > Suggestions? I wouldn't add a pattern for this. Actually I think the entire thing is a bad idea but thats another matter.
From: Joe Perches [email blocked] To: Alan Cox [email blocked] Subject: Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT Date: Mon, 13 Aug 2007 10:04:19 -0700 On Mon, 2007-08-13 at 17:35 +0100, Alan Cox wrote: > I wouldn't add a pattern for this. Back to:ARPD SUPPORT P: Jonathan Layes L: [email blocked] S: Maintained > Actually I think the entire thing is a > bad idea but thats another matter. Of course it's not an end-all solution, but what might work better?
From: Alan Cox [email blocked] To: Joe Perches [email blocked] Subject: Re: [PATCH] [70/2many] MAINTAINERS - ARPD SUPPORT Date: Mon, 13 Aug 2007 18:51:48 +0100 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 On Mon, 13 Aug 2007 10:04:19 -0700 Joe Perches [email blocked] wrote: > On Mon, 2007-08-13 at 17:35 +0100, Alan Cox wrote: > > I wouldn't add a pattern for this. > > Back to:ARPD SUPPORT > P: Jonathan Layes > L: [email blocked] > S: Maintained > > > Actually I think the entire thing is a > > bad idea but thats another matter. > > Of course it's not an end-all solution, > but what might work better? Working off the git tree as it shows who actually is making changes/updating stuff recently and why which is a major clue when tracing bugs
From: Simon Arlott [email blocked] CC: Linux Kernel Mailing List [email blocked] Subject: Re: [PATCH] [133/2many] MAINTAINERS - CONEXANT ACCESSRUNNER USB DRIVER Date: Mon, 13 Aug 2007 19:06:30 +0100 On 13/08/07 07:25, [email blocked] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches [email blocked] > > diff --git a/MAINTAINERS b/MAINTAINERS > index 594881d..d0a436a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1287,6 +1287,7 @@ M: [email blocked] > L: [email blocked] > W: http://accessrunner.sourceforge.net/ > S: Maintained > +F: drivers/usb/atm/cxacru.c > > CORETEMP HARDWARE MONITORING DRIVER > P: Rudolf Marek NAK: Strange patch title "[133/2many] ...." See Documentation/SubmittingPatches sections 1.2, 1.3, 1.5, 1.6, 3: http://marc.info/?l=linux-kernel&m=112112749912944&w=2 http://vger.kernel.org/z/zmailer-rrd-vger_SNMP_SYS_Load-Avg-5-min-G.html http://vger.kernel.org/z/zmailer-rrd-vger_SNMP_SYS_SpoolUsedSpace-kB-G.html -- Simon Arlott
From: Joe Perches [email blocked] To: Simon Arlott [email blocked] Cc: Linux Kernel Mailing List [email blocked] Subject: Re: [PATCH] [133/2many] MAINTAINERS - CONEXANT ACCESSRUNNER USB DRIVER Date: Mon, 13 Aug 2007 11:43:34 -0700 On Mon, 2007-08-13 at 19:06 +0100, Simon Arlott wrote: > NAK: Strange patch title "[133/2many] ...." I didn't expect these patches to be accepted as is actually. There isn't _that_ much difference between sending a 200KB patch file and what I sent. Nail could use the ability to add a threading header though.
From: Jan Engelhardt [email blocked] To: Joe Perches [email blocked] Subject: Re: [PATCH] [133/2many] MAINTAINERS - CONEXANT ACCESSRUNNER USB DRIVER Date: Mon, 13 Aug 2007 21:23:34 +0200 (CEST) On Aug 13 2007 11:43, Joe Perches wrote: > >There isn't _that_ much difference between sending a 200KB >patch file and what I sent. Nail could use the ability to >add a threading header though. On a technical side, there is a difference. 200 KB + 3 KB mail header = 203 KB. 550 mails each 3 KB = 1650 KB. Quite some `fun' for users with slower lines. (I was one of them not too long ago.) Jan
From: David Miller [email blocked] Subject: Re: [PATCH] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER Date: Sun, 12 Aug 2007 23:36:30 -0700 (PDT) Ok, 374 patches is just rediculious. So many patches eats up an enormous amount of mailing list resources, and for these patches in particular there are few reasons to split them up at all. The fact that the split up landed you at 300+ patches is a very good indication of that.
From: Joe Perches [email blocked] To: David Miller [email blocked] Subject: Re: [PATCH] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER Date: Sun, 12 Aug 2007 23:46:49 -0700 On Sun, 2007-08-12 at 23:36 -0700, David Miller wrote: > Ok, 374 patches is just rediculious. > > So many patches eats up an enormous amount of mailing list resources, > and for these patches in particular there are few reasons to split > them up at all. The fact that the split up landed you at 300+ patches > is a very good indication of that. More than ridiculous. Completely agree. I tried to send 1 patch over the last couple of days. Unfortunately, it's > 100KB and disappears into the void. How about 10 patches or so? What about maintainer sign offs? Personally, I don't think it's necessary, but for the subsystem maintainers like you, if or when the get_maintainers.pl get integrated into patch generation mechanisms, you might get more emails. Perhaps more than you want. Suggestions? One good thing by emailing all the listed maintainers, I've gotten several bounces for invalid addresses.
From: David Miller [email blocked] Subject: Re: [PATCH] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER Date: Mon, 13 Aug 2007 00:18:25 -0700 (PDT) From: Joe Perches [email blocked] Date: Sun, 12 Aug 2007 23:46:49 -0700 > I tried to send 1 patch over the last couple of days. > Unfortunately, it's > 100KB and disappears into the void. The posting limit is 400K for linux-kernel, netdev, and one or two of the other lists.
From: Joe Perches [email blocked] To: David Miller [email blocked] Subject: Re: [PATCH] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER Date: Mon, 13 Aug 2007 00:22:37 -0700 On Mon, 2007-08-13 at 00:18 -0700, David Miller wrote: > The posting limit is 400K for linux-kernel, netdev, and one > or two of the other lists. Apologies. Posted it twice over 2 days. Anyway, I supposed you could kill the spool entries if you want. cheers, Joe
From: Chris Wright [email blocked] Subject: Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE Date: Mon, 13 Aug 2007 11:55:36 -0700 * [email blocked] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches [email blocked] > > diff --git a/MAINTAINERS b/MAINTAINERS > index e4e1cc3..8395aba 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5153,6 +5153,11 @@ M: [email blocked] > L: [email blocked] > L: [email blocked] > S: Supported > +F: arch/i386/xen/ > +F: drivers/*/xen-*front.c > +F: drivers/xen/ > +F: include/asm-i386/xen/ > +F: include/xen/ I think this data will easily become stale. What is the point again?
From: Randy Dunlap [email blocked] To: Chris Wright [email blocked] Subject: Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE Date: Mon, 13 Aug 2007 12:10:05 -0700 On Mon, 13 Aug 2007 11:55:36 -0700 Chris Wright wrote: > * [email blocked] wrote: > > Add file pattern to MAINTAINER entry > > > > Signed-off-by: Joe Perches [email blocked] > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index e4e1cc3..8395aba 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5153,6 +5153,11 @@ M: [email blocked] > > L: [email blocked] > > L: [email blocked] > > S: Supported > > +F: arch/i386/xen/ > > +F: drivers/*/xen-*front.c > > +F: drivers/xen/ > > +F: include/asm-i386/xen/ > > +F: include/xen/ > > I think this data will easily become stale. What is the point again? Agreed. But not everyone wants to or should have to use git, so what are the alternatives? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
From: Chris Wright [email blocked] Subject: Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE Date: Mon, 13 Aug 2007 12:19:38 -0700 * Randy Dunlap wrote: > On Mon, 13 Aug 2007 11:55:36 -0700 Chris Wright wrote: > > * [email blocked] wrote: > > > +F: arch/i386/xen/ > > > +F: drivers/*/xen-*front.c > > > +F: drivers/xen/ > > > +F: include/asm-i386/xen/ > > > +F: include/xen/ > > > > I think this data will easily become stale. What is the point again? > > Agreed. But not everyone wants to or should have to use git, > so what are the alternatives? Between git (or gitweb), existing MAINTAINERS and a bit of common sense (or extra sleuthing), I never perceived a significant problem. Alternative could be to place info directly in source files. If not all of MAINTAINERS info, it could be a tag to reference the relevant MAINTAINERS entry. thanks, -chris
From: Adrian Bunk [email blocked] To: Chris Wright [email blocked] Subject: Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE Date: Mon, 13 Aug 2007 22:21:58 +0200 On Mon, Aug 13, 2007 at 12:19:38PM -0700, Chris Wright wrote: > * Randy Dunlap wrote: > > On Mon, 13 Aug 2007 11:55:36 -0700 Chris Wright wrote: > > > * [email blocked] wrote: > > > > +F: arch/i386/xen/ > > > > +F: drivers/*/xen-*front.c > > > > +F: drivers/xen/ > > > > +F: include/asm-i386/xen/ > > > > +F: include/xen/ > > > > > > I think this data will easily become stale. What is the point again? > > > > Agreed. But not everyone wants to or should have to use git, > > so what are the alternatives? > > Between git (or gitweb), existing MAINTAINERS and a bit of common > sense (or extra sleuthing), I never perceived a significant problem. For active kernel developers like you and me it's not a problem. But for other people it's non-trivial to always figure out who the maintainer of some part of the kernel is. > Alternative could be to place info directly in source files. If not > all of MAINTAINERS info, it could be a tag to reference the relevant > MAINTAINERS entry. Having the information in MAINTAINERS is what creates the least redundancies. > thanks, > -chris cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
From: Alan Cox [email blocked] Subject: Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE Date: Mon, 13 Aug 2007 21:54:50 +0100 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 > Agreed. But not everyone wants to or should have to use git, > so what are the alternatives? Export the recent git history each release into an XML file at known locations on the kernel web site. Wait for tools to appear
From: Valdis Kletnieks [email blocked] Subject: Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE Date: Mon, 13 Aug 2007 15:22:59 -0400 On Mon, 13 Aug 2007 12:10:05 PDT, Randy Dunlap said: > Agreed. But not everyone wants to or should have to use git, > so what are the alternatives? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree and start chasing down 'History' pointers? (Of course, mentioning that in Documentation/somewhere would be a good start)
From: Adrian Bunk [email blocked] Subject: Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE Date: Mon, 13 Aug 2007 22:13:24 +0200 On Mon, Aug 13, 2007 at 03:22:59PM -0400 wrote: > On Mon, 13 Aug 2007 12:10:05 PDT, Randy Dunlap said: > > > Agreed. But not everyone wants to or should have to use git, > > so what are the alternatives? > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree > > and start chasing down 'History' pointers? >... And that brings you what? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
From: Valdis Kletnieks [email blocked] Subject: Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE Date: Mon, 13 Aug 2007 16:32:19 -0400 On Mon, 13 Aug 2007 22:13:24 +0200, Adrian Bunk said: > On Mon, Aug 13, 2007 at 03:22:59PM -0400, Valdis.Kletnieks wrote: > > On Mon, 13 Aug 2007 12:10:05 PDT, Randy Dunlap said: > > > > > Agreed. But not everyone wants to or should have to use git, > > > so what are the alternatives? > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree > > > > and start chasing down 'History' pointers? > >... > > And that brings you what? You got a better alternative to 'git history' or 'git blame' to find who to cc: regarding a bug, feel free to propose it. ;)
From: Adrian Bunk [email blocked] Subject: Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE Date: Mon, 13 Aug 2007 22:47:20 +0200 On Mon, Aug 13, 2007 at 04:32:19PM -0400, Valdis.Kletnieks wrote: > On Mon, 13 Aug 2007 22:13:24 +0200, Adrian Bunk said: > > On Mon, Aug 13, 2007 at 03:22:59PM -0400, Valdis.Kletnieks wrote: > > > On Mon, 13 Aug 2007 12:10:05 PDT, Randy Dunlap said: > > > > > > > Agreed. But not everyone wants to or should have to use git, > > > > so what are the alternatives? > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree > > > > > > and start chasing down 'History' pointers? > > >... > > > > And that brings you what? > > You got a better alternative to 'git history' or 'git blame' to find who > to cc: regarding a bug, feel free to propose it. ;) Joe's patches cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
From: Joe Perches [email blocked] Subject: Bad addresses in MAINTAINERS Date: Mon, 13 Aug 2007 12:07:04 -0700 After that unfortunately large patch-bomb (apologies to all concerned), I received these fatal user-unknown bounces. Most of these bounces are for obsolete systems. For the lists, I'll change them to: [email blocked] But if anyone has a new email address and still wants to be in the maintainers file, please send. 3C359 NETWORK DRIVER OLYMPIC NETWORK DRIVER TOKEN-RING NETWORK DRIVER TMS380 TOKEN-RING NETWORK DRIVER L: [email blocked] USB DIAMOND RIO500 DRIVER P: Cesar Miquel M: [email blocked] USB SERIAL EMPEG EMPEG-CAR MARK I/II DRIVER P: Gary Brubaker M: [email blocked] TMS380 TOKEN-RING NETWORK DRIVER P: Adam Fritzler M: [email blocked] TUN/TAP driver L: [email blocked] STARFIRE/DURALAN NETWORK DRIVER P: Ion Badulescu M: [email blocked] SIS 5513 IDE CONTROLLER DRIVER P: Lionel Bouton M: Lionel.Bouton at inet6.fr MARVELL YUKON / SYSKONNECT DRIVER P: Mirko Lindner M: [email blocked] P: Ralph Roesler M: [email blocked] LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) L: [email blocked] INOTIFY P: John McCutchan M: [email blocked] INTEL FRAMEBUFFER DRIVER (excluding 810 and 815) P: Sylvain Meyer M: sylvain.meyer at worldonline.fr IMS TWINTURBO FRAMEBUFFER DRIVER P: Paul Mundt M: [email blocked] IDE/ATAPI FLOPPY DRIVERS P: Paul Bristow M: [email blocked] AEDSP16 DRIVER P: Riccardo Facchetti M: [email blocked] HIGH-SPEED SCC DRIVER FOR AX.25 P: Klaus Kudielka M: klaus.kudielka at ieee.org FRAME RELAY DLCI/FRAD (Sangoma drivers too) P: Mike McLagan M: mike.mclagan at linux.org FPU EMULATOR P: Bill Metzenthen M: [email blocked] DOUBLETALK DRIVER P: James R. Van Zandt M: [email blocked] BLACKFIN ARCHITECTURE P: Aubrey Li M: aubrey.li at analog.com P: Jerry Zeng M: jerry.zeng at analog.com 9P FILE SYSTEM P: Ron Minnich M: [email blocked] A2232 SERIAL BOARD DRIVER P: Enver Haase M: [email blocked] ACPI FAN DRIVER P: Konstantin A. Karasyov M: konstantin.a.karasyov at intel.com PER-TASK DELAY ACCOUNTING P: Shailabh Nagar M: [email blocked] PREEMPTIBLE KERNEL L: [email blocked] OLYMPIC NETWORK DRIVER P: Peter De Shrijver M: [email blocked] ZF MACHZ WATCHDOG P: Fernando Fuganti M: [email blocked] ZR36120 VIDEO FOR LINUX DRIVER P: Pauline Middelink M: [email blocked]
From: Alan Cox [email blocked] To: Joe Perches [email blocked] Subject: Re: Bad addresses in MAINTAINERS Date: Mon, 13 Aug 2007 21:56:07 +0100 Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 > 3C359 NETWORK DRIVER > OLYMPIC NETWORK DRIVER > TOKEN-RING NETWORK DRIVER > TMS380 TOKEN-RING NETWORK DRIVER > L: [email blocked] Probably linux-net For the others be careful. My mail system is probably like many others that decided you were an attack and some of them may well have bounced as a result
