Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-29 Thread Joe Perches 
On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote:
> On Thu, Jul 27, 2017 at 8:12 PM, Joe Perches  wrote:
> > 
> > I think it's better to centralize the MAINTAINERS
> > location in /MAINTAINERS/ than spread
> > them all over the tree given how many subsystems and
> > maintainerships are also spread around the tree.
> > 
> > But the get_maintainers patch I sent allows both
> > styles.
> 
> Possibly. I just did realize that we have one de-centralized
> maintainers file out there already, and have had for 3+ years:
> drivers/staging/unisys/MAINTAINERS.

That file should be deleted as it's duplicated
in the standard MAINTAINERS file

> One thing I like about the decentralized model is that it looks like
> we could automate the initial split fairly well based on F: patterns.
> Something like:
> 
>  - if we have a single F-pattern line, without directory wildcards,
> put the entry in the MAINTAINERS directory for that F-pattern

That would create more than 750 files.

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-29 Thread Joe Perches 
On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote:
> On Thu, Jul 27, 2017 at 8:12 PM, Joe Perches  wrote:
> > 
> > I think it's better to centralize the MAINTAINERS
> > location in /MAINTAINERS/ than spread
> > them all over the tree given how many subsystems and
> > maintainerships are also spread around the tree.
> > 
> > But the get_maintainers patch I sent allows both
> > styles.
> 
> Possibly. I just did realize that we have one de-centralized
> maintainers file out there already, and have had for 3+ years:
> drivers/staging/unisys/MAINTAINERS.

That file should be deleted as it's duplicated
in the standard MAINTAINERS file

> One thing I like about the decentralized model is that it looks like
> we could automate the initial split fairly well based on F: patterns.
> Something like:
> 
>  - if we have a single F-pattern line, without directory wildcards,
> put the entry in the MAINTAINERS directory for that F-pattern

That would create more than 750 files.

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-28 Thread Joe Perches 
On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote:
> So we'd have files like "rdma", "dma", "omap", "pm", "dri", "pci",
> "wireless" etc, all of which sound sane.
[]
> it looks like a promising approach to me, and I like how
> the names seem to end up all fairly sane.
> 
> Comments?

Seems somewhat reasonable as a starting point.

There are many entries that have multiple mailing lists
that complicate the ability to script the idea though.

And perhaps more descriptive names than pm and mm
would also be more useful.

ACPI COMPONENT ARCHITECTURE (ACPICA)
L:  linux-a...@vger.kernel.org
L:  de...@acpica.org
ALTERA TRIPLE SPEED ETHERNET DRIVER
L:  net...@vger.kernel.org
L:  nios2-...@lists.rocketboards.org (moderated for non-subscribers)
ALTERA UART/JTAG UART SERIAL DRIVERS
L:  linux-ser...@vger.kernel.org
L:  nios2-...@lists.rocketboards.org (moderated for non-subscribers)
ANALOG DEVICES INC ASOC DRIVERS
L:  adi-buildroot-de...@lists.sourceforge.net (moderated for 
non-subscribers)
L:  alsa-de...@alsa-project.org (moderated for non-subscribers)
AOA (Apple Onboard Audio) ALSA DRIVER
L:  linuxppc-...@lists.ozlabs.org
L:  alsa-de...@alsa-project.org (moderated for non-subscribers)
ARM/Amlogic Meson SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-amlo...@lists.infradead.org
ARM/ASPEED I2C DRIVER
L:  linux-...@vger.kernel.org
L:  open...@lists.ozlabs.org
ARM/IGEP MACHINE SUPPORT
L:  linux-o...@vger.kernel.org
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek RTC DRIVER
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek USB3 PHY DRIVER
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/OXNAS platform support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-ox...@lists.tuxfamily.org (moderated for non-subscribers)
ARM/QUALCOMM SUPPORT
L:  linux-arm-...@vger.kernel.org
L:  linux-...@vger.kernel.org
ARM/Rockchip SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-rockc...@lists.infradead.org
ARM/SAMSUNG EXYNOS ARM ARCHITECTURES
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT
L:  linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/TEXAS INSTRUMENT KEYSTONE ClOCKSOURCE
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-kernel@vger.kernel.org
ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
L:  acpi4asus-u...@lists.sourceforge.net
L:  platform-driver-...@vger.kernel.org
ATM
L:  linux-atm-gene...@lists.sourceforge.net (moderated for non-subscribers)
L:  net...@vger.kernel.org
ATMEL XDMA DRIVER
L:  linux-arm-ker...@lists.infradead.org
L:  dmaeng...@vger.kernel.org
B43 WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  b43-...@lists.infradead.org
B43LEGACY WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  b43-...@lists.infradead.org
BPF (Safe dynamic programs and tools)
L:  net...@vger.kernel.org
L:  linux-kernel@vger.kernel.org
BROADCOM B53 ETHERNET SWITCH DRIVER
L:  net...@vger.kernel.org
L:  openwrt-de...@lists.openwrt.org (subscribers-only)
BROADCOM BCM2835 ARM ARCHITECTURE
L:  linux-rpi-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  brcm80211-dev-list@broadcom.com
BROADCOM STB NAND FLASH DRIVER
L:  linux-...@lists.infradead.org
L:  bcm-kernel-feedback-l...@broadcom.com
BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS
L:  linux...@vger.kernel.org
L:  linux-samsung-...@vger.kernel.org
CCREE ARM TRUSTZONE CRYPTOCELL 700 REE DRIVER
L:  linux-cry...@vger.kernel.org
L:  driverdev-de...@linuxdriverproject.org
CHINESE DOCUMENTATION
L:  xiyoulinuxkernelgr...@googlegroups.com

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-28 Thread Joe Perches 
On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote:
> So we'd have files like "rdma", "dma", "omap", "pm", "dri", "pci",
> "wireless" etc, all of which sound sane.
[]
> it looks like a promising approach to me, and I like how
> the names seem to end up all fairly sane.
> 
> Comments?

Seems somewhat reasonable as a starting point.

There are many entries that have multiple mailing lists
that complicate the ability to script the idea though.

And perhaps more descriptive names than pm and mm
would also be more useful.

ACPI COMPONENT ARCHITECTURE (ACPICA)
L:  linux-a...@vger.kernel.org
L:  de...@acpica.org
ALTERA TRIPLE SPEED ETHERNET DRIVER
L:  net...@vger.kernel.org
L:  nios2-...@lists.rocketboards.org (moderated for non-subscribers)
ALTERA UART/JTAG UART SERIAL DRIVERS
L:  linux-ser...@vger.kernel.org
L:  nios2-...@lists.rocketboards.org (moderated for non-subscribers)
ANALOG DEVICES INC ASOC DRIVERS
L:  adi-buildroot-de...@lists.sourceforge.net (moderated for 
non-subscribers)
L:  alsa-de...@alsa-project.org (moderated for non-subscribers)
AOA (Apple Onboard Audio) ALSA DRIVER
L:  linuxppc-...@lists.ozlabs.org
L:  alsa-de...@alsa-project.org (moderated for non-subscribers)
ARM/Amlogic Meson SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-amlo...@lists.infradead.org
ARM/ASPEED I2C DRIVER
L:  linux-...@vger.kernel.org
L:  open...@lists.ozlabs.org
ARM/IGEP MACHINE SUPPORT
L:  linux-o...@vger.kernel.org
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek RTC DRIVER
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek USB3 PHY DRIVER
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-media...@lists.infradead.org (moderated for non-subscribers)
ARM/OXNAS platform support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-ox...@lists.tuxfamily.org (moderated for non-subscribers)
ARM/QUALCOMM SUPPORT
L:  linux-arm-...@vger.kernel.org
L:  linux-...@vger.kernel.org
ARM/Rockchip SoC support
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-rockc...@lists.infradead.org
ARM/SAMSUNG EXYNOS ARM ARCHITECTURES
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT
L:  linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
L:  linux-arm-ker...@lists.infradead.org
L:  linux-me...@vger.kernel.org
ARM/TEXAS INSTRUMENT KEYSTONE ClOCKSOURCE
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-kernel@vger.kernel.org
ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
L:  acpi4asus-u...@lists.sourceforge.net
L:  platform-driver-...@vger.kernel.org
ATM
L:  linux-atm-gene...@lists.sourceforge.net (moderated for non-subscribers)
L:  net...@vger.kernel.org
ATMEL XDMA DRIVER
L:  linux-arm-ker...@lists.infradead.org
L:  dmaeng...@vger.kernel.org
B43 WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  b43-...@lists.infradead.org
B43LEGACY WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  b43-...@lists.infradead.org
BPF (Safe dynamic programs and tools)
L:  net...@vger.kernel.org
L:  linux-kernel@vger.kernel.org
BROADCOM B53 ETHERNET SWITCH DRIVER
L:  net...@vger.kernel.org
L:  openwrt-de...@lists.openwrt.org (subscribers-only)
BROADCOM BCM2835 ARM ARCHITECTURE
L:  linux-rpi-ker...@lists.infradead.org (moderated for non-subscribers)
L:  linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
L:  linux-wirel...@vger.kernel.org
L:  brcm80211-dev-list@broadcom.com
BROADCOM STB NAND FLASH DRIVER
L:  linux-...@lists.infradead.org
L:  bcm-kernel-feedback-l...@broadcom.com
BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS
L:  linux...@vger.kernel.org
L:  linux-samsung-...@vger.kernel.org
CCREE ARM TRUSTZONE CRYPTOCELL 700 REE DRIVER
L:  linux-cry...@vger.kernel.org
L:  driverdev-de...@linuxdriverproject.org
CHINESE DOCUMENTATION
L:  xiyoulinuxkernelgr...@googlegroups.com

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-28 Thread Linus Torvalds 
On Thu, Jul 27, 2017 at 8:12 PM, Joe Perches  wrote:
>
> I think it's better to centralize the MAINTAINERS
> location in /MAINTAINERS/ than spread
> them all over the tree given how many subsystems and
> maintainerships are also spread around the tree.
>
> But the get_maintainers patch I sent allows both
> styles.

Possibly. I just did realize that we have one de-centralized
maintainers file out there already, and have had for 3+ years:
drivers/staging/unisys/MAINTAINERS.

One thing I like about the decentralized model is that it looks like
we could automate the initial split fairly well based on F: patterns.
Something like:

 - if we have a single F-pattern line, without directory wildcards,
put the entry in the MAINTAINERS directory for that F-pattern

 - else keep it in the top-level MAINTAINERS file

because everything else I looked at kind of sucked. The "first word of
the description" works really well for a couple of cases, but really
badly for the majority.

But my favorite model right now is to actually do it by the "L:"
entry, and then remove the host name and the common parts from the
email name ("devel", "dev", "kernel", "linux" etc).

And then *if* we have multiple entries (arbitrary cut-off: 5) for the
same base (so the rule would be that we never have a MAINTAINERS file
with just a single entry like that unisys one), we'd split it out and
use "MAINTAINERS/xyz" for those entries.

But we'd still need a fallback for the "rest".

Because doing it by mailing list superficially looks like it might
work very well, we have things like this:

  5 L: io...@lists.linux-foundation.org
  5 L: keyri...@vger.kernel.org
  5 L: linux-bl...@vger.kernel.org
  6 L: linux-arm-...@vger.kernel.org
  6 L: linux-samsung-...@vger.kernel.org
  7 L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
  7 L: linux-security-mod...@vger.kernel.org
  7 L: linux-w...@vger.kernel.org
  8 L: linux-a...@vger.kernel.org
  8 L: linux-fsde...@vger.kernel.org
  8 L: linux-...@vger.kernel.org
  8 L: linux-ser...@vger.kernel.org
  8 L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
  9 L: adi-buildroot-de...@lists.sourceforge.net (moderated for
non-subscribers)
  9 L: linux-h...@vger.kernel.org
  9 L: linux...@kvack.org
 11 L: k...@vger.kernel.org
 11 L: linux-...@vger.kernel.org
 12 L: virtualizat...@lists.linux-foundation.org
 13 L: linux-renesas-...@vger.kernel.org
 13 L: linux-s...@vger.kernel.org
 16 L: linux-...@vger.kernel.org
 16 L: linux-m...@linux-mips.org
 17 L: linux-g...@vger.kernel.org
 18 L: linux-cry...@vger.kernel.org
 18 L: linux-...@lists.infradead.org
 20 L: linux-arm-ker...@lists.infradead.org
 20 L: linux-in...@vger.kernel.org
 22 L: linux-...@vger.kernel.org
 23 L: linux-e...@vger.kernel.org
 23 L: linux-fb...@vger.kernel.org
 23 L: linux-r...@vger.kernel.org
 25 L: linux-o...@vger.kernel.org
 26 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
 27 L: linux...@vger.kernel.org
 28 L: dri-de...@lists.freedesktop.org
 29 L: linuxppc-...@lists.ozlabs.org
 33 L: linux-...@vger.kernel.org
 35 L: platform-driver-...@vger.kernel.org
 39 L: linux-...@vger.kernel.org
 44 L: linux-wirel...@vger.kernel.org
 46 L: linux-hw...@vger.kernel.org
 54 L: linux-kernel@vger.kernel.org
 57 L: linux-s...@vger.kernel.org
122 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
134 L: net...@vger.kernel.org
187 L: linux-me...@vger.kernel.org

so we'd actually be able to create an entry like "media" with 187
maintainers entries automatically based on that heuristic. Same goes
for a lot of other entries, and we'd end up with about 50 files in
MAINTAINERS which sounds manageable but still usefully split up.

So we'd have files like "rdma", "dma", "omap", "pm", "dri", "pci",
"wireless" etc, all of which sound sane.

(The "linux-kernel@vger.kernel.org" L: entry above would automatically
become moot, because the "filter out the common parts" turns it into
an empty name, which is actually correct - it implies no specific
subsystem)

I generated the above with trivial grep scripting, so some of them may
end up not working or having wrong counts just due to having multiple
L: lines, but it looks like a promising approach to me, and I like how
the names seem to end up all fairly sane.

Comments?

  Linus

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-28 Thread Linus Torvalds 
On Thu, Jul 27, 2017 at 8:12 PM, Joe Perches  wrote:
>
> I think it's better to centralize the MAINTAINERS
> location in /MAINTAINERS/ than spread
> them all over the tree given how many subsystems and
> maintainerships are also spread around the tree.
>
> But the get_maintainers patch I sent allows both
> styles.

Possibly. I just did realize that we have one de-centralized
maintainers file out there already, and have had for 3+ years:
drivers/staging/unisys/MAINTAINERS.

One thing I like about the decentralized model is that it looks like
we could automate the initial split fairly well based on F: patterns.
Something like:

 - if we have a single F-pattern line, without directory wildcards,
put the entry in the MAINTAINERS directory for that F-pattern

 - else keep it in the top-level MAINTAINERS file

because everything else I looked at kind of sucked. The "first word of
the description" works really well for a couple of cases, but really
badly for the majority.

But my favorite model right now is to actually do it by the "L:"
entry, and then remove the host name and the common parts from the
email name ("devel", "dev", "kernel", "linux" etc).

And then *if* we have multiple entries (arbitrary cut-off: 5) for the
same base (so the rule would be that we never have a MAINTAINERS file
with just a single entry like that unisys one), we'd split it out and
use "MAINTAINERS/xyz" for those entries.

But we'd still need a fallback for the "rest".

Because doing it by mailing list superficially looks like it might
work very well, we have things like this:

  5 L: io...@lists.linux-foundation.org
  5 L: keyri...@vger.kernel.org
  5 L: linux-bl...@vger.kernel.org
  6 L: linux-arm-...@vger.kernel.org
  6 L: linux-samsung-...@vger.kernel.org
  7 L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers)
  7 L: linux-security-mod...@vger.kernel.org
  7 L: linux-w...@vger.kernel.org
  8 L: linux-a...@vger.kernel.org
  8 L: linux-fsde...@vger.kernel.org
  8 L: linux-...@vger.kernel.org
  8 L: linux-ser...@vger.kernel.org
  8 L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
  9 L: adi-buildroot-de...@lists.sourceforge.net (moderated for
non-subscribers)
  9 L: linux-h...@vger.kernel.org
  9 L: linux...@kvack.org
 11 L: k...@vger.kernel.org
 11 L: linux-...@vger.kernel.org
 12 L: virtualizat...@lists.linux-foundation.org
 13 L: linux-renesas-...@vger.kernel.org
 13 L: linux-s...@vger.kernel.org
 16 L: linux-...@vger.kernel.org
 16 L: linux-m...@linux-mips.org
 17 L: linux-g...@vger.kernel.org
 18 L: linux-cry...@vger.kernel.org
 18 L: linux-...@lists.infradead.org
 20 L: linux-arm-ker...@lists.infradead.org
 20 L: linux-in...@vger.kernel.org
 22 L: linux-...@vger.kernel.org
 23 L: linux-e...@vger.kernel.org
 23 L: linux-fb...@vger.kernel.org
 23 L: linux-r...@vger.kernel.org
 25 L: linux-o...@vger.kernel.org
 26 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
 27 L: linux...@vger.kernel.org
 28 L: dri-de...@lists.freedesktop.org
 29 L: linuxppc-...@lists.ozlabs.org
 33 L: linux-...@vger.kernel.org
 35 L: platform-driver-...@vger.kernel.org
 39 L: linux-...@vger.kernel.org
 44 L: linux-wirel...@vger.kernel.org
 46 L: linux-hw...@vger.kernel.org
 54 L: linux-kernel@vger.kernel.org
 57 L: linux-s...@vger.kernel.org
122 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
134 L: net...@vger.kernel.org
187 L: linux-me...@vger.kernel.org

so we'd actually be able to create an entry like "media" with 187
maintainers entries automatically based on that heuristic. Same goes
for a lot of other entries, and we'd end up with about 50 files in
MAINTAINERS which sounds manageable but still usefully split up.

So we'd have files like "rdma", "dma", "omap", "pm", "dri", "pci",
"wireless" etc, all of which sound sane.

(The "linux-kernel@vger.kernel.org" L: entry above would automatically
become moot, because the "filter out the common parts" turns it into
an empty name, which is actually correct - it implies no specific
subsystem)

I generated the above with trivial grep scripting, so some of them may
end up not working or having wrong counts just due to having multiple
L: lines, but it looks like a promising approach to me, and I like how
the names seem to end up all fairly sane.

Comments?

  Linus

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-27 Thread Joe Perches 
On Thu, 2017-07-27 at 19:43 -0700, Linus Torvalds wrote:
> On Thu, Jul 27, 2017 at 5:30 PM, Joe Perches  wrote:
> > 
> > Maybe add a reordering of the patterns so that each pattern list
> > is in a specific order too
> 
> I don't think this is wrong per se, but I'm not sure I want to get
> into the merge hell any more than we are already.
> 
> Maybe when/if that file is actually split up?

Fine by me.

The get_maintainer patch is a prereq to any split-up.

There are a bunch of little niggly patches that
should go in that remove/update bad F: patterns too
one day.

Given the differences between -next and your tree,
I think only Andrew and quilt would do a decent
job of getting individual patches merged.

Unless you want to take them.

I think it's better to centralize the MAINTAINERS
location in /MAINTAINERS/ than spread
them all over the tree given how many subsystems and
maintainerships are also spread around the tree.

But the get_maintainers patch I sent allows both
styles.

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-27 Thread Joe Perches 
On Thu, 2017-07-27 at 19:43 -0700, Linus Torvalds wrote:
> On Thu, Jul 27, 2017 at 5:30 PM, Joe Perches  wrote:
> > 
> > Maybe add a reordering of the patterns so that each pattern list
> > is in a specific order too
> 
> I don't think this is wrong per se, but I'm not sure I want to get
> into the merge hell any more than we are already.
> 
> Maybe when/if that file is actually split up?

Fine by me.

The get_maintainer patch is a prereq to any split-up.

There are a bunch of little niggly patches that
should go in that remove/update bad F: patterns too
one day.

Given the differences between -next and your tree,
I think only Andrew and quilt would do a decent
job of getting individual patches merged.

Unless you want to take them.

I think it's better to centralize the MAINTAINERS
location in /MAINTAINERS/ than spread
them all over the tree given how many subsystems and
maintainerships are also spread around the tree.

But the get_maintainers patch I sent allows both
styles.

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-27 Thread Linus Torvalds 
On Thu, Jul 27, 2017 at 5:30 PM, Joe Perches  wrote:
>
> Maybe add a reordering of the patterns so that each pattern list
> is in a specific order too

I don't think this is wrong per se, but I'm not sure I want to get
into the merge hell any more than we are already.

Maybe when/if that file is actually split up?

  Linus

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-27 Thread Linus Torvalds 
On Thu, Jul 27, 2017 at 5:30 PM, Joe Perches  wrote:
>
> Maybe add a reordering of the patterns so that each pattern list
> is in a specific order too

I don't think this is wrong per se, but I'm not sure I want to get
into the merge hell any more than we are already.

Maybe when/if that file is actually split up?

  Linus

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-27 Thread Joe Perches 
On Sun, 2017-07-23 at 16:14 -0700, Linus Torvalds wrote:
> On Sun, Jul 23, 2017 at 1:00 PM, Linus Torvalds
>  wrote:
> > 
> > Anyway, clearly my script showed something. I think my script is still
> > doing the right thing, it's just that the input is questionable.
> 
> I added a few actual checks for the error cases to the script, fixed
> up the problems, and committed the end result.
> 
> My perl skills are still very dubious, so I'm not proud of the script,
> but it's there as "scripts/parse-mainainers.pl" now. The "output
> sorted result" part could *easily* be changed into "output sorted
> result into separate files based on the first word of the header" or
> something.
> 
> But in the meantime, at least that MAINTAINERS file should _really_ be
> alpha-sorted now.

Maybe add a reordering of the patterns so that each pattern list
is in a specific order too

---
 scripts/parse-maintainers.pl | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/scripts/parse-maintainers.pl b/scripts/parse-maintainers.pl
index a0fe34349b24..03e7405af1a3 100644
--- a/scripts/parse-maintainers.pl
+++ b/scripts/parse-maintainers.pl
@@ -4,7 +4,7 @@ use strict;
 
 my %map;
 
-# sort comparison function
+# sort comparison functions
 sub by_category($$) {
 my ($a, $b) = @_;
 
@@ -18,17 +18,45 @@ sub by_category($$) {
 $a cmp $b;
 }
 
+sub by_pattern($$) {
+my ($a, $b) = @_;
+my $preferred_order = 'MRPLWQTBSKCFX';
+
+my $rtn;
+$a = uc(substr($a, 0, 1));
+$b = uc(substr($b, 0, 1));
+
+my $a_index = index($preferred_order, $a);
+my $b_index = index($preferred_order, $b);
+
+$a_index = 1000 if ($a_index == -1);
+$b_index = 1000 if ($b_index == -1);
+
+if ($a_index < $b_index) {
+   return -1;
+} elsif ($a_index == $b_index) {
+   return 0;
+} else {
+   return 1;
+}
+}
+
 sub alpha_output {
 my $key;
-my $sort_method = \_category;
 my $sep = "";
 
-foreach $key (sort $sort_method keys %map) {
+foreach $key (sort by_category keys %map) {
 if ($key ne " ") {
 print $sep . $key . "\n";
 $sep = "\n";
 }
-print $map{$key};
+   if ($key eq " ") {
+   print $map{$key};
+   } else {
+   foreach my $pattern (sort by_pattern split('\n', $map{$key})) {
+   print($pattern . "\n");
+   }
+   }
 }
 }
 

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-27 Thread Joe Perches 
On Sun, 2017-07-23 at 16:14 -0700, Linus Torvalds wrote:
> On Sun, Jul 23, 2017 at 1:00 PM, Linus Torvalds
>  wrote:
> > 
> > Anyway, clearly my script showed something. I think my script is still
> > doing the right thing, it's just that the input is questionable.
> 
> I added a few actual checks for the error cases to the script, fixed
> up the problems, and committed the end result.
> 
> My perl skills are still very dubious, so I'm not proud of the script,
> but it's there as "scripts/parse-mainainers.pl" now. The "output
> sorted result" part could *easily* be changed into "output sorted
> result into separate files based on the first word of the header" or
> something.
> 
> But in the meantime, at least that MAINTAINERS file should _really_ be
> alpha-sorted now.

Maybe add a reordering of the patterns so that each pattern list
is in a specific order too

---
 scripts/parse-maintainers.pl | 36 
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/scripts/parse-maintainers.pl b/scripts/parse-maintainers.pl
index a0fe34349b24..03e7405af1a3 100644
--- a/scripts/parse-maintainers.pl
+++ b/scripts/parse-maintainers.pl
@@ -4,7 +4,7 @@ use strict;
 
 my %map;
 
-# sort comparison function
+# sort comparison functions
 sub by_category($$) {
 my ($a, $b) = @_;
 
@@ -18,17 +18,45 @@ sub by_category($$) {
 $a cmp $b;
 }
 
+sub by_pattern($$) {
+my ($a, $b) = @_;
+my $preferred_order = 'MRPLWQTBSKCFX';
+
+my $rtn;
+$a = uc(substr($a, 0, 1));
+$b = uc(substr($b, 0, 1));
+
+my $a_index = index($preferred_order, $a);
+my $b_index = index($preferred_order, $b);
+
+$a_index = 1000 if ($a_index == -1);
+$b_index = 1000 if ($b_index == -1);
+
+if ($a_index < $b_index) {
+   return -1;
+} elsif ($a_index == $b_index) {
+   return 0;
+} else {
+   return 1;
+}
+}
+
 sub alpha_output {
 my $key;
-my $sort_method = \_category;
 my $sep = "";
 
-foreach $key (sort $sort_method keys %map) {
+foreach $key (sort by_category keys %map) {
 if ($key ne " ") {
 print $sep . $key . "\n";
 $sep = "\n";
 }
-print $map{$key};
+   if ($key eq " ") {
+   print $map{$key};
+   } else {
+   foreach my $pattern (sort by_pattern split('\n', $map{$key})) {
+   print($pattern . "\n");
+   }
+   }
 }
 }
 

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Joe Perches 
On Sun, 2017-07-23 at 16:14 -0700, Linus Torvalds wrote:
> On Sun, Jul 23, 2017 at 1:00 PM, Linus Torvalds
>  wrote:
> > 
> > Anyway, clearly my script showed something. I think my script is still
> > doing the right thing, it's just that the input is questionable.
> 
> I added a few actual checks for the error cases to the script, fixed
> up the problems, and committed the end result.
> 
> My perl skills are still very dubious, so I'm not proud of the script,



No one should be _that_ proud of perl skilz.
Not even monks.

> but it's there as "scripts/parse-mainainers.pl" now. The "output
> sorted result" part could *easily* be changed into "output sorted
> result into separate files based on the first word of the header" or
> something.

And match $map{$case} for various patterns too.

> But in the meantime, at least that MAINTAINERS file should _really_ be
> alpha-sorted now.

Thanks.

And for easy diffs the script should write out both
a modified MAINTAINERS without the matched sections
and a new file with the matched sections.

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Joe Perches 
On Sun, 2017-07-23 at 16:14 -0700, Linus Torvalds wrote:
> On Sun, Jul 23, 2017 at 1:00 PM, Linus Torvalds
>  wrote:
> > 
> > Anyway, clearly my script showed something. I think my script is still
> > doing the right thing, it's just that the input is questionable.
> 
> I added a few actual checks for the error cases to the script, fixed
> up the problems, and committed the end result.
> 
> My perl skills are still very dubious, so I'm not proud of the script,



No one should be _that_ proud of perl skilz.
Not even monks.

> but it's there as "scripts/parse-mainainers.pl" now. The "output
> sorted result" part could *easily* be changed into "output sorted
> result into separate files based on the first word of the header" or
> something.

And match $map{$case} for various patterns too.

> But in the meantime, at least that MAINTAINERS file should _really_ be
> alpha-sorted now.

Thanks.

And for easy diffs the script should write out both
a modified MAINTAINERS without the matched sections
and a new file with the matched sections.

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Linus Torvalds 
On Sun, Jul 23, 2017 at 1:00 PM, Linus Torvalds
 wrote:
>
> Anyway, clearly my script showed something. I think my script is still
> doing the right thing, it's just that the input is questionable.

I added a few actual checks for the error cases to the script, fixed
up the problems, and committed the end result.

My perl skills are still very dubious, so I'm not proud of the script,
but it's there as "scripts/parse-mainainers.pl" now. The "output
sorted result" part could *easily* be changed into "output sorted
result into separate files based on the first word of the header" or
something.

But in the meantime, at least that MAINTAINERS file should _really_ be
alpha-sorted now.

  Linus

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Linus Torvalds 
On Sun, Jul 23, 2017 at 1:00 PM, Linus Torvalds
 wrote:
>
> Anyway, clearly my script showed something. I think my script is still
> doing the right thing, it's just that the input is questionable.

I added a few actual checks for the error cases to the script, fixed
up the problems, and committed the end result.

My perl skills are still very dubious, so I'm not proud of the script,
but it's there as "scripts/parse-mainainers.pl" now. The "output
sorted result" part could *easily* be changed into "output sorted
result into separate files based on the first word of the header" or
something.

But in the meantime, at least that MAINTAINERS file should _really_ be
alpha-sorted now.

  Linus

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Joe Perches 
On Sun, 2017-07-23 at 13:00 -0700, Linus Torvalds wrote:
> it looks like there were four copies of "GREYBUS PROTOCOLS
> DRIVERS". WTF? I didn't check if there was something else odd going
> on.
> 
> I guess they'd need to be made unique somehow too.

right.

Unfortunate about the duplicate section headers.

get_maintainers doesn't care what the section headers are
but your script does.  

Easy fix though prior to running the script.

$ grep -P "^[0-9A-Za-z][^:]" MAINTAINERS|sort|uniq -c | sort -rn
  4 GREYBUS PROTOCOLS DRIVERS
  2 SYNC FILE FRAMEWORK
  2 NOKIA N900 CAMERA SUPPORT (ET8EK8 SENSOR, AD5820 FOCUS)

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Joe Perches 
On Sun, 2017-07-23 at 13:00 -0700, Linus Torvalds wrote:
> it looks like there were four copies of "GREYBUS PROTOCOLS
> DRIVERS". WTF? I didn't check if there was something else odd going
> on.
> 
> I guess they'd need to be made unique somehow too.

right.

Unfortunate about the duplicate section headers.

get_maintainers doesn't care what the section headers are
but your script does.  

Easy fix though prior to running the script.

$ grep -P "^[0-9A-Za-z][^:]" MAINTAINERS|sort|uniq -c | sort -rn
  4 GREYBUS PROTOCOLS DRIVERS
  2 SYNC FILE FRAMEWORK
  2 NOKIA N900 CAMERA SUPPORT (ET8EK8 SENSOR, AD5820 FOCUS)

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Joe Perches 
On Sun, 2017-07-23 at 12:49 -0700, Linus Torvalds wrote:
> Ok, so I already applied your alpha-ordering patch, but it just annoyed me 
> that
> 
>  (a) the ordering wasn't complete
> 
>  (b) this wasn't scripted.
> 
> However, the sane way of scripting it is clearly not to do it in C,
> which I'd be comfy with, because that would be insane.
> 
> Instead, it should be done in perl. Except my perl-fu is so horribly
> horribly bad that I'm a bit ashamed to show the end result.
> 
> Does anybody have actual real perl skills? Because somebody should
> double-check my appended script-from-hell.
> 
> ANYWAY. One reason I did this was because *if* we want to split up the
> MAINTAINERS file, I absolutely refuse to do it by hand. It needs to be
> automated. I'm not going to apply a patch - I'm going to apply a
> *script*, and commit the end result along with the doc about what the
> script was (so that then I have an inevitable conflict due to this big
> re-org, I can resolve the conflict by re-running the script on the
> side that wasn't part of the re-org, rather than having to do nasty
> things).
> 
> And this script could easily be extended to automate the scripting. So
> please, can somebody with perl-fu say that "yeah, that's the right
> perl model", or point me to what I did wrong?
> 
> The end result looks ok. I can run
> 
> perl parse-maintainers.pl < MAINTAINERS > outfile
> 
> and the end result is actually a *properly* sorted MAINTAINERS file as
> far as I can tell.
> 
> Comments?

That works OK except for this section
where there are 2 header lines

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

If you take up the patch I sent for that
before you run the script, it should be OK.

https://patchwork.kernel.org/patch/9857337/

I'll send a get_maintainers patch that allows a few
different styles of MAINTAINERS files separately.

o A single top level MAINTAINERS file
o A MAINTAINERS directory with multiple section files
o MAINTAINERS files distributed around the kernel source tree

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Joe Perches 
On Sun, 2017-07-23 at 12:49 -0700, Linus Torvalds wrote:
> Ok, so I already applied your alpha-ordering patch, but it just annoyed me 
> that
> 
>  (a) the ordering wasn't complete
> 
>  (b) this wasn't scripted.
> 
> However, the sane way of scripting it is clearly not to do it in C,
> which I'd be comfy with, because that would be insane.
> 
> Instead, it should be done in perl. Except my perl-fu is so horribly
> horribly bad that I'm a bit ashamed to show the end result.
> 
> Does anybody have actual real perl skills? Because somebody should
> double-check my appended script-from-hell.
> 
> ANYWAY. One reason I did this was because *if* we want to split up the
> MAINTAINERS file, I absolutely refuse to do it by hand. It needs to be
> automated. I'm not going to apply a patch - I'm going to apply a
> *script*, and commit the end result along with the doc about what the
> script was (so that then I have an inevitable conflict due to this big
> re-org, I can resolve the conflict by re-running the script on the
> side that wasn't part of the re-org, rather than having to do nasty
> things).
> 
> And this script could easily be extended to automate the scripting. So
> please, can somebody with perl-fu say that "yeah, that's the right
> perl model", or point me to what I did wrong?
> 
> The end result looks ok. I can run
> 
> perl parse-maintainers.pl < MAINTAINERS > outfile
> 
> and the end result is actually a *properly* sorted MAINTAINERS file as
> far as I can tell.
> 
> Comments?

That works OK except for this section
where there are 2 header lines

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

If you take up the patch I sent for that
before you run the script, it should be OK.

https://patchwork.kernel.org/patch/9857337/

I'll send a get_maintainers patch that allows a few
different styles of MAINTAINERS files separately.

o A single top level MAINTAINERS file
o A MAINTAINERS directory with multiple section files
o MAINTAINERS files distributed around the kernel source tree

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Linus Torvalds 
On Sun, Jul 23, 2017 at 12:49 PM, Linus Torvalds
 wrote:
>
> The end result looks ok. I can run
>
> perl parse-maintainers.pl < MAINTAINERS > outfile
>
> and the end result is actually a *properly* sorted MAINTAINERS file as
> far as I can tell.

Yeah, there's something wrong there. I end up with fewer lines than I
started with.

I suspect there is some duplicated section header - the way I do that
associated array, any duplicate entry with the same header would end
up being collapsed into just the last entry.

In fact, it looks like there were four copies of "GREYBUS PROTOCOLS
DRIVERS". WTF? I didn't check if there was something else odd going
on.

I guess they'd need to be made unique somehow too.

Anyway, clearly my script showed something. I think my script is still
doing the right thing, it's just that the input is questionable.

 Linus

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Linus Torvalds 
On Sun, Jul 23, 2017 at 12:49 PM, Linus Torvalds
 wrote:
>
> The end result looks ok. I can run
>
> perl parse-maintainers.pl < MAINTAINERS > outfile
>
> and the end result is actually a *properly* sorted MAINTAINERS file as
> far as I can tell.

Yeah, there's something wrong there. I end up with fewer lines than I
started with.

I suspect there is some duplicated section header - the way I do that
associated array, any duplicate entry with the same header would end
up being collapsed into just the last entry.

In fact, it looks like there were four copies of "GREYBUS PROTOCOLS
DRIVERS". WTF? I didn't check if there was something else odd going
on.

I guess they'd need to be made unique somehow too.

Anyway, clearly my script showed something. I think my script is still
doing the right thing, it's just that the input is questionable.

 Linus

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Linus Torvalds 
Ok, so I already applied your alpha-ordering patch, but it just annoyed me that

 (a) the ordering wasn't complete

 (b) this wasn't scripted.

However, the sane way of scripting it is clearly not to do it in C,
which I'd be comfy with, because that would be insane.

Instead, it should be done in perl. Except my perl-fu is so horribly
horribly bad that I'm a bit ashamed to show the end result.

Does anybody have actual real perl skills? Because somebody should
double-check my appended script-from-hell.

ANYWAY. One reason I did this was because *if* we want to split up the
MAINTAINERS file, I absolutely refuse to do it by hand. It needs to be
automated. I'm not going to apply a patch - I'm going to apply a
*script*, and commit the end result along with the doc about what the
script was (so that then I have an inevitable conflict due to this big
re-org, I can resolve the conflict by re-running the script on the
side that wasn't part of the re-org, rather than having to do nasty
things).

And this script could easily be extended to automate the scripting. So
please, can somebody with perl-fu say that "yeah, that's the right
perl model", or point me to what I did wrong?

The end result looks ok. I can run

perl parse-maintainers.pl < MAINTAINERS > outfile

and the end result is actually a *properly* sorted MAINTAINERS file as
far as I can tell.

Comments?

   Linus

---
#!/usr/bin/perl -w

use strict;

my %map;

# sort comparison function
sub by_category($$) {
my ($a, $b) = @_;

$a = uc $a;
$b = uc $b;

# This always sorts last
$a =~ s/THE REST/ZZ/g;
$b =~ s/THE REST/ZZ/g;

$a cmp $b;
}

sub alpha_output {
my $key;
my $sort_method = \_category;

foreach $key (sort $sort_method keys %map) {
if ($key ne " ") {
print $key;
}
print $map{$key};
}
}

sub file_input {
my $lastline = "";
my $case = " ";
$map{$case} = "";

while (<>) {
my $line = $_;

# Pattern line?
if ($line =~ m/^([A-Z]):\s*(.*)/) {
if ($lastline eq "") {
$map{$case} = $map{$case} . $line;
next;
}
$case = $lastline;
$map{$case} = $line;
$lastline = "";
next;
}

$map{$case} = $map{$case} . $lastline;
$lastline = $line;
}
$map{$case} = $map{$case} . $lastline;
}

_input;
_output;
exit(0);

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-23 Thread Linus Torvalds 
Ok, so I already applied your alpha-ordering patch, but it just annoyed me that

 (a) the ordering wasn't complete

 (b) this wasn't scripted.

However, the sane way of scripting it is clearly not to do it in C,
which I'd be comfy with, because that would be insane.

Instead, it should be done in perl. Except my perl-fu is so horribly
horribly bad that I'm a bit ashamed to show the end result.

Does anybody have actual real perl skills? Because somebody should
double-check my appended script-from-hell.

ANYWAY. One reason I did this was because *if* we want to split up the
MAINTAINERS file, I absolutely refuse to do it by hand. It needs to be
automated. I'm not going to apply a patch - I'm going to apply a
*script*, and commit the end result along with the doc about what the
script was (so that then I have an inevitable conflict due to this big
re-org, I can resolve the conflict by re-running the script on the
side that wasn't part of the re-org, rather than having to do nasty
things).

And this script could easily be extended to automate the scripting. So
please, can somebody with perl-fu say that "yeah, that's the right
perl model", or point me to what I did wrong?

The end result looks ok. I can run

perl parse-maintainers.pl < MAINTAINERS > outfile

and the end result is actually a *properly* sorted MAINTAINERS file as
far as I can tell.

Comments?

   Linus

---
#!/usr/bin/perl -w

use strict;

my %map;

# sort comparison function
sub by_category($$) {
my ($a, $b) = @_;

$a = uc $a;
$b = uc $b;

# This always sorts last
$a =~ s/THE REST/ZZ/g;
$b =~ s/THE REST/ZZ/g;

$a cmp $b;
}

sub alpha_output {
my $key;
my $sort_method = \_category;

foreach $key (sort $sort_method keys %map) {
if ($key ne " ") {
print $key;
}
print $map{$key};
}
}

sub file_input {
my $lastline = "";
my $case = " ";
$map{$case} = "";

while (<>) {
my $line = $_;

# Pattern line?
if ($line =~ m/^([A-Z]):\s*(.*)/) {
if ($lastline eq "") {
$map{$case} = $map{$case} . $line;
next;
}
$case = $lastline;
$map{$case} = $line;
$lastline = "";
next;
}

$map{$case} = $map{$case} . $lastline;
$lastline = $line;
}
$map{$case} = $map{$case} . $lastline;
}

_input;
_output;
exit(0);

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-21 Thread Linus Torvalds 
On Fri, Jul 21, 2017 at 1:32 PM, Randy Dunlap  wrote:
>
> and send with correct file encoding!

Congratulations, you were indeed successful in fixing whatever locale
issue that was biting you.

  Linus

Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-21 Thread Linus Torvalds 
On Fri, Jul 21, 2017 at 1:32 PM, Randy Dunlap  wrote:
>
> and send with correct file encoding!

Congratulations, you were indeed successful in fixing whatever locale
issue that was biting you.

  Linus

[PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-21 Thread Randy Dunlap 
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 
Acked-by: Andrew Morton 
---
 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
and send with correct file encoding!

--- 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:

[PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering

2017-07-21 Thread Randy Dunlap 
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 
Acked-by: Andrew Morton 
---
 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
and send with correct file encoding!

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