Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Thu, 2017-07-20 at 11:03 -0700, Linus Torvalds wrote: > On Thu, Jul 20, 2017 at 9:48 AM, Joe Perches wrote: > > > > Same general concept, but then an expectation would be > > relative paths for filename patterns. > > No, I actually think we really should require the filename patterns to > be absolute, even if the MAINTAINERS file might be deep in the > hierarchy. So do I but I bet dollars to doughnuts it happens because expectations are what people assume so use too. > So file patterns absolutely would need to remain relative to the top > of the repository, not to the location of the MAINTAINERS file. yup.
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Thu, Jul 20, 2017 at 9:48 AM, Joe Perches wrote: > > Same general concept, but then an expectation would be > relative paths for filename patterns. No, I actually think we really should require the filename patterns to be absolute, even if the MAINTAINERS file might be deep in the hierarchy. Even if you have some particular driver that it under "drivers/misc/crazy/random/odd.c", and your MAINTAINERS entry is somewhere in that drivers hierachy, you might still want to refer to a documentation file somewhere else, for example. So file patterns absolutely would need to remain relative to the top of the repository, not to the location of the MAINTAINERS file. Linus
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Thu, 2017-07-20 at 20:54 +1000, Michael Ellerman wrote: > Joe Perches writes: > > > On Wed, 2017-07-19 at 21:24 -0700, Linus Torvalds wrote: > > > On Wed, Jul 19, 2017 at 6:05 PM, Joe Perches wrote: > > > > > > > > Just for ease of manipulation and not breaking the script much, > > > > I'd suggest just having a MAINTAINERS directory and stuffing > > > > each of the sections into separate files. > > > > > > > > The script would only need to add $ cat MAINTAINERS/* as input. > > > > > > So I don't mind the idea of just making MAINTAINERS a directory, but I > > > don't think we want to so far as to make one file per entry. That's > > > what, 1500+ files tiny files or so? Seems a bit excessive. > > > > > > Maybe we can just do the prefix thing and just do 26 files A-Z > > > instead? Or maybe go by first word (so all the ARM things would go in > > > one place?) > > > > > > A couple of hundred files sounds fine. A couple of thousand files > > > sound a bit excessive.. > > > > $ ls MAINTAINERS.tmp/ | wc -l > > 1735 > > > > > > > > A couple thousand individual maintainers is also excessive. > > > > Most maintainers in MAINTAINERS aren't really much involved. > > > > A-Z is arbitrary and still difficult to find because it's > > not descriptive as to whatever is actually maintained. > > > > As a concept I think individual files would be better. > > But maybe grouping by subsystem instead of by letter. > > > > Maybe by mirroring the directory layouts. > > > > > > drivers/net > > drivers/scsi > > Or what about putting separate MAINTAINERS files in the hierarchy at > whichever level makes the most sense, ie. not too big and not too small. Same general concept, but then an expectation would be relative paths for filename patterns. It's still hard to do when subsystem maintainers cross. drivers/net vs drivers/net/ethernet/ vs drivers/net/wireless. etc.. > eg. > > arch/x86/MAINTAINERS > arch/arm64/MAINTAINERS > arch/powerpc/MAINTAINERS > ... > net/MAINTAINERS > mm/MAINTAINERS > drivers/net/MAINTAINERS > drivers/media/MAINTAINERS > drivers/scsi/MAINTAINERS > drivers/gpu/drm/MAINTAINERS > drivers/MAINTAINERS > > That way we might end up with 20-50 (?) files, but most of the conflicts > would be handled by a sub system maintainer before Linus sees them.
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
Joe Perches writes: > On Wed, 2017-07-19 at 21:24 -0700, Linus Torvalds wrote: >> On Wed, Jul 19, 2017 at 6:05 PM, Joe Perches wrote: >> > >> > Just for ease of manipulation and not breaking the script much, >> > I'd suggest just having a MAINTAINERS directory and stuffing >> > each of the sections into separate files. >> > >> > The script would only need to add $ cat MAINTAINERS/* as input. >> >> So I don't mind the idea of just making MAINTAINERS a directory, but I >> don't think we want to so far as to make one file per entry. That's >> what, 1500+ files tiny files or so? Seems a bit excessive. >> >> Maybe we can just do the prefix thing and just do 26 files A-Z >> instead? Or maybe go by first word (so all the ARM things would go in >> one place?) >> >> A couple of hundred files sounds fine. A couple of thousand files >> sound a bit excessive.. > > $ ls MAINTAINERS.tmp/ | wc -l > 1735 > > > > A couple thousand individual maintainers is also excessive. > > Most maintainers in MAINTAINERS aren't really much involved. > > A-Z is arbitrary and still difficult to find because it's > not descriptive as to whatever is actually maintained. > > As a concept I think individual files would be better. > But maybe grouping by subsystem instead of by letter. > > Maybe by mirroring the directory layouts. > > > drivers/net > drivers/scsi Or what about putting separate MAINTAINERS files in the hierarchy at whichever level makes the most sense, ie. not too big and not too small. eg. arch/x86/MAINTAINERS arch/arm64/MAINTAINERS arch/powerpc/MAINTAINERS ... net/MAINTAINERS mm/MAINTAINERS drivers/net/MAINTAINERS drivers/media/MAINTAINERS drivers/scsi/MAINTAINERS drivers/gpu/drm/MAINTAINERS drivers/MAINTAINERS That way we might end up with 20-50 (?) files, but most of the conflicts would be handled by a sub system maintainer before Linus sees them. We might still need a top level file for "other", for things that really don't fit anywhere. Files would be allowed to have patterns that match elsewhere in the tree, so eg. arch files could match against arch specific code in drivers. And you can still get the full list just with: $ find . -name MAINTAINERS | xargs ca cheers
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, Jul 19, 2017 at 9:43 PM, Joe Perches wrote: > > As a concept I think individual files would be better. > But maybe grouping by subsystem instead of by letter. Yes. Grouped by subsystem would be nice. And maybe we could start with just a few bigger groups, and split them as people step on each others toes or it gets annoying. Of course, the "group by subsystem" has the problem that because it's to some degree a choice (unlike "group by first letter or first word"), then people end up having different judgments and you have duplication of information that then gets out of sync etc. Linus
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, Jul 19, 2017 at 9:36 PM, Theodore Ts'o wrote: >> >> Maybe we can just do the prefix thing and just do 26 files A-Z >> instead? Or maybe go by first word (so all the ARM things would go in >> one place?) > > Is that really going to help with merge conflicts? It might help keep > things more in order, but if there is a merge conflict caused by two > changes to adjacent entries causing patch "fuzz", splitting things > into 26 files A-Z isn't going to significantly decrease the odds of > this happening. So it would actually help me a lot with conflicts - not because they'd happen less, but because *when* they happen, the end result is much easier to look at. When I resolve a conflict, I always want to look at the commits that cause the conflict. So what do I do? I do gitk HEAD...MERGE_HEAD and then with the MAINTAINERS file, I literally see *all* those hundreds of changes. You can just do gitk v4.12.. MAINTAINERS with the current tree to get a feel for it. It's just nasty. Now imagine that you have to find the two commits that clash among the 100+ commits that have absolutely nothing to do with those two. If we split the MAINTAINER file up, I might still get the exact same number of conflicts, but when I look at the history of the individual files, it will be much saner. That's particularly true if we split up by "first word" (eg "ADAPTEC" or "ARM" or "SECURITY" or whatever), when instead of having tens of different development threads that all end up touching one single MAINTAINERS file (with most of it being entirely irrelevant to one particular conflict), you presumably have just a very small handful (and those are now likely much more relevant to the conflict at hand). Basically, handling four (or whatever) conflicts per merge window is nothing. But they are particularly _annoying_ conflicts. (They are never actually _hard_ conflicts, or very meaningful either. They are just annoying and frustrating exactly because they are so pointlessly much harder to find than they really should need to be). Linus
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, 2017-07-19 at 21:24 -0700, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 6:05 PM, Joe Perches wrote: > > > > Just for ease of manipulation and not breaking the script much, > > I'd suggest just having a MAINTAINERS directory and stuffing > > each of the sections into separate files. > > > > The script would only need to add $ cat MAINTAINERS/* as input. > > So I don't mind the idea of just making MAINTAINERS a directory, but I > don't think we want to so far as to make one file per entry. That's > what, 1500+ files tiny files or so? Seems a bit excessive. > > Maybe we can just do the prefix thing and just do 26 files A-Z > instead? Or maybe go by first word (so all the ARM things would go in > one place?) > > A couple of hundred files sounds fine. A couple of thousand files > sound a bit excessive.. $ ls MAINTAINERS.tmp/ | wc -l 1735 A couple thousand individual maintainers is also excessive. Most maintainers in MAINTAINERS aren't really much involved. A-Z is arbitrary and still difficult to find because it's not descriptive as to whatever is actually maintained. As a concept I think individual files would be better. But maybe grouping by subsystem instead of by letter. Maybe by mirroring the directory layouts. drivers/net drivers/scsi etc...
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, Jul 19, 2017 at 09:24:13PM -0700, Linus Torvalds wrote: > So I don't mind the idea of just making MAINTAINERS a directory, but I > don't think we want to so far as to make one file per entry. That's > what, 1500+ files tiny files or so? Seems a bit excessive. > > Maybe we can just do the prefix thing and just do 26 files A-Z > instead? Or maybe go by first word (so all the ARM things would go in > one place?) Is that really going to help with merge conflicts? It might help keep things more in order, but if there is a merge conflict caused by two changes to adjacent entries causing patch "fuzz", splitting things into 26 files A-Z isn't going to significantly decrease the odds of this happening. It would seem to me that keeping a single file, and if we have a program which sanity checks changes to the Maintainers format (warns of missing required fields or unknown fields, or entries inserted out of order, etc.) perhaps that would accomplish most of what we are looking for? Or we could do something really hacky, like add "\n\n" between each entry to avoid merge conflicts caused by adjacent changes or adjacent inserts? But that's an idea that is probably too ugly to live... - Ted
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, Jul 19, 2017 at 6:05 PM, Joe Perches wrote: > > Just for ease of manipulation and not breaking the script much, > I'd suggest just having a MAINTAINERS directory and stuffing > each of the sections into separate files. > > The script would only need to add $ cat MAINTAINERS/* as input. So I don't mind the idea of just making MAINTAINERS a directory, but I don't think we want to so far as to make one file per entry. That's what, 1500+ files tiny files or so? Seems a bit excessive. Maybe we can just do the prefix thing and just do 26 files A-Z instead? Or maybe go by first word (so all the ARM things would go in one place?) A couple of hundred files sounds fine. A couple of thousand files sound a bit excessive.. Linus
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, 2017-07-19 at 18:05 -0700, Joe Perches wrote: > On Wed, 2017-07-19 at 17:08 -0700, Linus Torvalds wrote: > > (b) we could split this thing up some sane way. > > > > Anybody got any ideas? [] > Just for ease of manipulation and not breaking the script much, > I'd suggest just having a MAINTAINERS directory and stuffing > each of the sections into separate files. > > The script would only need to add $ cat MAINTAINERS/* as input. Maybe something like the script below to break up the MAINTAINERS file into separate files. It also uses underscores for spaces in the section header -> filename translation. This seems to work OK except for this single section which doesn't follow the normal single line section header style. EDAC-XGENE APPLIED MICRO (APM) X-GENE SOC EDAC M: Loc Ho S: Supported F: drivers/edac/xgene_edac.c F: Documentation/devicetree/bindings/edac/apm-xgene-edac.txt That one would need manual fixup. --- $ cat separate_MAINTAINERS.bash mkdir MAINTAINERS.tmp sed -n '3,122p' MAINTAINERS > MAINTAINERS.tmp/00-README sed -n '131,50p' MAINTAINERS | while read line; do if [[ ! "$line" =~ ^[A-Z0-9a-z][A-Z0-9a-z\.\-] ]]; then echo "bad line: $line" continue fi file=MAINTAINERS.tmp/$(echo -n $line | sed -r -e 's/\s+/_/g' -e 's@/@-@g' -e 's/_-_/-/' -e 's/:*$//') echo "$line" > $file while read line; do if [[ ! $line =~ ^[A-Z]: ]]; then break fi echo "$line" >> $file done done $
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, 2017-07-19 at 17:08 -0700, Linus Torvalds wrote: > I can easily just look at the reject and fix it, but I don't really > want to. Why? Because I hate the MAINTAINERS file. > > It's the most painful file for merging too, because everybody touches > it - kind of like the old "one single Kconfig file" was back in the > bad old days. > For example, just during this merge window: > > $ git rev-list --count --no-merges v4.12.. MAINTAINERS > 112 > > and while most of them obviously didn't cause any conflicts (there > were four this cycle), it's still my least favourite "stupid work". > That file pretty consistently gets 100+ changes to it: > > v4.1: 87 > v4.2: 109 > v4.3: 94 > v4.4: 91 > v4.5: 118 > v4.6: 98 > v4.7: 112 > v4.8: 121 > v4.9: 128 > v4.10: 135 > v4.11: 78 > v4.12: 127 > > So I'm wondering if > > (a) we could add a script to do the alphabetical ordering properly. > > (b) we could split this thing up some sane way. > > Anybody got any ideas? > > I'm throwing out _one_ idea: split it up by the main F: line, so that > maintainership information ends up being hierarchical like the Kconfig > files. Teach "get_maintainer.pl" to just do "find . -name > MAINTAINERS" instead? Just for ease of manipulation and not breaking the script much, I'd suggest just having a MAINTAINERS directory and stuffing each of the sections into separate files. The script would only need to add $ cat MAINTAINERS/* as input.
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On 07/19/2017 05:53 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 5:35 PM, Linus Torvalds > wrote: >> >> Your mailer is crap, and destroys utf-8 characters. In particular: >> >> -M: MichaÅ‚ MirosÅ‚aw > > Using pseudo-MIME-encoding, that was actually (before my cut-and-paste > mangled it even more): > > Micha=c3=85=c2=82 Miros=c3=85=c2=82aw > >> should be >> >> -M: Michał Mirosław > > And the correct utf-8 is > > Micha=C5=82 Miros=C5=82aw > > and it *looks* like what happened is that something thought the input > was Latin1, and converted the Latin1 to UTF-8. > > So the utf-8 character 'ł' (two bytes: =C5=82) was seen as two Latin1 > character bytes: =c5 and =82. > > And then each of those were converted mindlessly to utf-8, so the 'c5' > character became '=C3=85' and the '82' character became '=c2=82'. > > So you have something that believes that a source file was latin1. > > May I suggest just making absolutely *everything* on your system use a > utf-8 locale? > > Because in this day and age, anything but utf-8 is just woefully > broken crud. "Just say no". Thanks for the diagnosis. Will do. -- ~Randy
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, Jul 19, 2017 at 5:35 PM, Linus Torvalds wrote: > > Your mailer is crap, and destroys utf-8 characters. In particular: > > -M: MichaÅ‚ MirosÅ‚aw Using pseudo-MIME-encoding, that was actually (before my cut-and-paste mangled it even more): Micha=c3=85=c2=82 Miros=c3=85=c2=82aw > should be > > -M: Michał Mirosław And the correct utf-8 is Micha=C5=82 Miros=C5=82aw and it *looks* like what happened is that something thought the input was Latin1, and converted the Latin1 to UTF-8. So the utf-8 character 'ł' (two bytes: =C5=82) was seen as two Latin1 character bytes: =c5 and =82. And then each of those were converted mindlessly to utf-8, so the 'c5' character became '=C3=85' and the '82' character became '=c2=82'. So you have something that believes that a source file was latin1. May I suggest just making absolutely *everything* on your system use a utf-8 locale? Because in this day and age, anything but utf-8 is just woefully broken crud. "Just say no". Linus
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, Jul 19, 2017 at 5:26 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap wrote: >> >> Must be small and stupid. It applies cleanly for me. >> Do you have changes that are not pushed out publicly? > > Nope, my private tree matches the public one. Oh, I see it. Your mailer is crap, and destroys utf-8 characters. In particular: -M: MichaÅ‚ MirosÅ‚aw should be -M: Michał Mirosław I'm not sure what part of your flow is broken, because your mailer *claims* that it used Content-Type: text/plain; charset=utf-8 but it very much did not. When you attached that file, it did some odd character conversion crud. There may be other examples of this, but that's the one I see and the one that caused that to fail in that hunk. Linus
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap wrote: > > Must be small and stupid. It applies cleanly for me. > Do you have changes that are not pushed out publicly? Nope, my private tree matches the public one. The failure happens at the chunk for line 5086, fwiw. You don't seem to have used git to generate the patch, so it doesn't show the git blob ID's (which is a really nice way to show exactly which version of a file the diff was generated against). My current MAINTAINER file has git object ID 02994f42aacb07e79b9facf9881e3f0983929c0b Linus
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On 07/19/2017 05:08 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton > wrote: >> >> Linus, can you please grab this? > > Ugh. It doesn't apply cleanly. Probably for some really small stupid reason. Must be small and stupid. It applies cleanly for me. Do you have changes that are not pushed out publicly? > I can easily just look at the reject and fix it, but I don't really > want to. Why? Because I hate the MAINTAINERS file. -- ~Randy
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On 07/19/2017 05:08 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton > wrote: >> >> Linus, can you please grab this? > > Ugh. It doesn't apply cleanly. Probably for some really small stupid reason. > > I can easily just look at the reject and fix it, but I don't really > want to. Why? Because I hate the MAINTAINERS file. > > It's the most painful file for merging too, because everybody touches > it - kind of like the old "one single Kconfig file" was back in the > bad old days. > > For example, just during this merge window: > > $ git rev-list --count --no-merges v4.12.. MAINTAINERS > 112 > > and while most of them obviously didn't cause any conflicts (there > were four this cycle), it's still my least favourite "stupid work". > That file pretty consistently gets 100+ changes to it: > > v4.1: 87 > v4.2: 109 > v4.3: 94 > v4.4: 91 > v4.5: 118 > v4.6: 98 > v4.7: 112 > v4.8: 121 > v4.9: 128 > v4.10: 135 > v4.11: 78 > v4.12: 127 > > So I'm wondering if > > (a) we could add a script to do the alphabetical ordering properly. Yeah, I have already thought about that one. I may get around tuit one day. Or maybe Joe could/would. > (b) we could split this thing up some sane way. makes sense. > Anybody got any ideas? (c) funnel all changes thru Andrew (but really foo should be able to make changes to her MAINTAINERS entry) > I'm throwing out _one_ idea: split it up by the main F: line, so that > maintainership information ends up being hierarchical like the Kconfig > files. Teach "get_maintainer.pl" to just do "find . -name > MAINTAINERS" instead? > > I'm not saying that's a great idea (quite often the "main F: line" > might be ambiguous), but it's the most obvious one. > > This is not a _huge_ problem, but it has been a slight annoyance for a > long time now. So it would be good to maybe at least discuss it a bit. -- ~Randy
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, Jul 19, 2017 at 5:08 PM, Linus Torvalds wrote: > > I'm throwing out _one_ idea: split it up by the main F: line, so that > maintainership information ends up being hierarchical like the Kconfig > files. Teach "get_maintainer.pl" to just do "find . -name > MAINTAINERS" instead? For a more radical change, get rid of the MAINTAINERS file entirely, and put the information into the Kconfig files - kind of like the "help" text, except with the rules. It's probably not really workable, but in many ways the maintainership often tends to more closely match the configuration than the tree layout, and some of the fields would actually make sense for the help thing (eg the whole support status, but also the web-page with status/info pointer). Again - just throwing this out as a "please discuss" thing. Linus
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton wrote: > > Linus, can you please grab this? Ugh. It doesn't apply cleanly. Probably for some really small stupid reason. I can easily just look at the reject and fix it, but I don't really want to. Why? Because I hate the MAINTAINERS file. It's the most painful file for merging too, because everybody touches it - kind of like the old "one single Kconfig file" was back in the bad old days. For example, just during this merge window: $ git rev-list --count --no-merges v4.12.. MAINTAINERS 112 and while most of them obviously didn't cause any conflicts (there were four this cycle), it's still my least favourite "stupid work". That file pretty consistently gets 100+ changes to it: v4.1: 87 v4.2: 109 v4.3: 94 v4.4: 91 v4.5: 118 v4.6: 98 v4.7: 112 v4.8: 121 v4.9: 128 v4.10: 135 v4.11: 78 v4.12: 127 So I'm wondering if (a) we could add a script to do the alphabetical ordering properly. (b) we could split this thing up some sane way. Anybody got any ideas? I'm throwing out _one_ idea: split it up by the main F: line, so that maintainership information ends up being hierarchical like the Kconfig files. Teach "get_maintainer.pl" to just do "find . -name MAINTAINERS" instead? I'm not saying that's a great idea (quite often the "main F: line" might be ambiguous), but it's the most obvious one. This is not a _huge_ problem, but it has been a slight annoyance for a long time now. So it would be good to maybe at least discuss it a bit. Hmm? Linus
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, 2017-07-19 at 14:40 -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Fix major alphabetic errors. No attempt to fix items that all begin > with the same word (like ARM, BROADCOM, DRM, EDAC, FREESCALE, INTEL, > OMAP, PCI, SAMSUNG, TI, USB, etc.). [] > -APPARMOR SECURITY MODULE > -M: John Johansen > -L: appar...@lists.ubuntu.com (subscribers-only, general discussion) > -W: apparmor.wiki.kernel.org > -T: git git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git > -S: Supported > -F: security/apparmor/ > -F: Documentation/admin-guide/LSM/apparmor.rst > - > -LOADPIN SECURITY MODULE > -M: Kees Cook > -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git > lsm/loadpin > -S: Supported > -F: security/loadpin/ > -F: Documentation/admin-guide/LSM/LoadPin.rst > - > -YAMA SECURITY MODULE > -M: Kees Cook > -T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git > yama/tip > -S: Supported > -F: security/yama/ > -F: Documentation/admin-guide/LSM/Yama.rst Instead of reordering these, perhaps it'd be getter to rename them. SECURITY MODULE - APPARMOR SECURITY MODULE - LOADPIN SECURITY MODULE - YAMA
Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
On Wed, 19 Jul 2017 14:40:20 -0700 Randy Dunlap wrote: > Fix major alphabetic errors. No attempt to fix items that all begin > with the same word (like ARM, BROADCOM, DRM, EDAC, FREESCALE, INTEL, > OMAP, PCI, SAMSUNG, TI, USB, etc.). > > (diffstat +/- is different by one line because TI KEYSTONE MULTICORE > had 2 blank lines after it.) Acked-by: Andrew Morton Linus, can you please grab this?
[PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
From: Randy Dunlap Fix major alphabetic errors. No attempt to fix items that all begin with the same word (like ARM, BROADCOM, DRM, EDAC, FREESCALE, INTEL, OMAP, PCI, SAMSUNG, TI, USB, etc.). (diffstat +/- is different by one line because TI KEYSTONE MULTICORE had 2 blank lines after it.) Signed-off-by: Randy Dunlap --- MAINTAINERS | 1683 -- 1 file changed, 841 insertions(+), 842 deletions(-) v2: approx. 10 more corrections v3: fixes for 4.13-rc1 changes v4: update for git-current --- lnx-413-rc1.orig/MAINTAINERS +++ lnx-413-rc1/MAINTAINERS @@ -492,13 +492,6 @@ S: Maintained F: Documentation/hwmon/adt7475 F: drivers/hwmon/adt7475.c -ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346) -M: Michael Hennerich -W: http://wiki.analog.com/ADXL345 -W: http://ez.analog.com/community/linux-device-drivers -S: Supported -F: drivers/input/misc/adxl34x.c - ADVANSYS SCSI DRIVER M: Matthew Wilcox M: Hannes Reinecke @@ -507,6 +500,13 @@ S: Maintained F: Documentation/scsi/advansys.txt F: drivers/scsi/advansys.c +ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346) +M: Michael Hennerich +W: http://wiki.analog.com/ADXL345 +W: http://ez.analog.com/community/linux-device-drivers +S: Supported +F: drivers/input/misc/adxl34x.c + AEDSP16 DRIVER M: Riccardo Facchetti S: Maintained @@ -872,6 +872,15 @@ F: include/linux/apm_bios.h F: include/uapi/linux/apm_bios.h F: drivers/char/apm-emulation.c +APPARMOR SECURITY MODULE +M: John Johansen +L: appar...@lists.ubuntu.com (subscribers-only, general discussion) +W: apparmor.wiki.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git +S: Supported +F: security/apparmor/ +F: Documentation/admin-guide/LSM/apparmor.rst + APPLE BCM5974 MULTITOUCH DRIVER M: Henrik Rydberg L: linux-in...@vger.kernel.org @@ -930,6 +939,12 @@ S: Maintained F: drivers/video/fbdev/arcfb.c F: drivers/video/fbdev/core/fb_defio.c +ARC PGU DRM DRIVER +M: Alexey Brodkin +S: Supported +F: drivers/gpu/drm/arc/ +F: Documentation/devicetree/bindings/display/snps,arcpgu.txt + ARCNET NETWORK LAYER M: Michael Grzeschik L: net...@vger.kernel.org @@ -937,12 +952,6 @@ S: Maintained F: drivers/net/arcnet/ F: include/uapi/linux/if_arcnet.h -ARC PGU DRM DRIVER -M: Alexey Brodkin -S: Supported -F: drivers/gpu/drm/arc/ -F: Documentation/devicetree/bindings/display/snps,arcpgu.txt - ARM ARCHITECTED TIMER DRIVER M: Mark Rutland M: Marc Zyngier @@ -2207,21 +2216,10 @@ T: git git://git.kernel.org/pub/scm/linu S: Supported F: drivers/net/wireless/ath/ath6kl/ -WILOCITY WIL6210 WIRELESS DRIVER -M: Maya Erez -L: linux-wirel...@vger.kernel.org -L: wil6...@qca.qualcomm.com -S: Supported -W: http://wireless.kernel.org/en/users/Drivers/wil6210 -F: drivers/net/wireless/ath/wil6210/ -F: include/uapi/linux/wil6210_uapi.h - -CARL9170 LINUX COMMUNITY WIRELESS DRIVER -M: Christian Lamparter -L: linux-wirel...@vger.kernel.org -W: http://wireless.kernel.org/en/users/Drivers/carl9170 +ATI_REMOTE2 DRIVER +M: Ville Syrjala S: Maintained -F: drivers/net/wireless/ath/carl9170/ +F: drivers/input/misc/ati_remote2.c ATK0110 HWMON DRIVER M: Luca Tettamanti @@ -2229,11 +2227,6 @@ L: linux-hw...@vger.kernel.org S: Maintained F: drivers/hwmon/asus_atk0110.c -ATI_REMOTE2 DRIVER -M: Ville Syrjala -S: Maintained -F: drivers/input/misc/ati_remote2.c - ATLX ETHERNET DRIVERS M: Jay Cliburn M: Chris Snook @@ -2507,13 +2500,11 @@ W: https://linuxtv.org S: Supported F: drivers/media/platform/sti/bdisp -DELTA ST MEDIA DRIVER -M: Hugues Fruchet -L: linux-me...@vger.kernel.org -T: git git://linuxtv.org/media_tree.git -W: https://linuxtv.org -S: Supported -F: drivers/media/platform/sti/delta +BECKHOFF CX5020 ETHERCAT MASTER DRIVER +M: Dariusz Marcinkiewicz +L: net...@vger.kernel.org +S: Maintained +F: drivers/net/ethernet/ec_bhf.c BEFS FILE SYSTEM M: Luis de Bethencourt @@ -2523,11 +2514,13 @@ T: git git://git.kernel.org/pub/scm/linu F: Documentation/filesystems/befs.txt F: fs/befs/ -BECKHOFF CX5020 ETHERCAT MASTER DRIVER -M: Dariusz Marcinkiewicz -L: net...@vger.kernel.org +BFQ I/O SCHEDULER +M: Paolo Valente +M: Jens Axboe +L: linux-bl...@vger.kernel.org S: Maintained -F: drivers/net/ethernet/ec_bhf.c +F: block/bfq-* +F: Documentation/block/bfq-iosched.txt BFS FILE SYSTEM M: "Tigran A. Aivazian" @@ -2606,14 +2599,6 @@ F: block/ F: kernel/trace/blktrace.c F: lib/sbitmap.c -BFQ I/O SCHEDULER -M: Paolo Valente -M: Jens Axboe -L: linux-bl...@vger.kernel.org
