Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1694351 > unrolled thread

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

Started byLinus Torvalds <torvalds@linux-foundation.org>
First post2017-07-23 21:50 +0200
Last post2017-07-23 22:10 +0200
Articles 12 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-23 21:50 +0200
    Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-23 22:10 +0200
      Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Joe Perches <joe@perches.com> - 2017-07-23 22:20 +0200
      Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-24 01:20 +0200
        Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Joe Perches <joe@perches.com> - 2017-07-24 03:40 +0200
        Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Joe Perches <joe@perches.com> - 2017-07-28 02:40 +0200
          Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-28 04:50 +0200
            Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Joe Perches <joe@perches.com> - 2017-07-28 05:20 +0200
              Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-29 00:40 +0200
                Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Joe Perches <joe@perches.com> - 2017-07-29 03:10 +0200
                Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Joe Perches <joe@perches.com> - 2017-07-29 19:50 +0200
    Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Joe Perches <joe@perches.com> - 2017-07-23 22:10 +0200

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

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2017-07-23 21:50 +0200
SubjectRe: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering
Message-ID<u6v33-3ff-3@gated-at.bofh.it>
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/ZZZZZZ/g;
    $b =~ s/THE REST/ZZZZZZ/g;

    $a cmp $b;
}

sub alpha_output {
    my $key;
    my $sort_method = \&by_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;
}

&file_input;
&alpha_output;
exit(0);

[toc] | [next] | [standalone]

#1694352

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2017-07-23 22:10 +0200
Message-ID<u6vmp-3Au-3@gated-at.bofh.it>
In reply to#1694351
On Sun, Jul 23, 2017 at 12:49 PM, Linus Torvalds
<torvalds@linux-foundation.org> 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

[toc] | [prev] | [next] | [standalone]

#1694356

FromJoe Perches <joe@perches.com>
Date2017-07-23 22:20 +0200
Message-ID<u6vw5-3Dt-11@gated-at.bofh.it>
In reply to#1694352
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)

[toc] | [prev] | [next] | [standalone]

#1694364

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2017-07-24 01:20 +0200
Message-ID<u6yki-5kZ-5@gated-at.bofh.it>
In reply to#1694352
On Sun, Jul 23, 2017 at 1:00 PM, Linus Torvalds
<torvalds@linux-foundation.org> 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

[toc] | [prev] | [next] | [standalone]

#1694393

FromJoe Perches <joe@perches.com>
Date2017-07-24 03:40 +0200
Message-ID<u6AvL-6Bf-7@gated-at.bofh.it>
In reply to#1694364
On Sun, 2017-07-23 at 16:14 -0700, Linus Torvalds wrote:
> On Sun, Jul 23, 2017 at 1:00 PM, Linus Torvalds
> <torvalds@linux-foundation.org> 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,

<shrug>

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.

[toc] | [prev] | [next] | [standalone]

#1698384

FromJoe Perches <joe@perches.com>
Date2017-07-28 02:40 +0200
Message-ID<u81tT-4QH-1@gated-at.bofh.it>
In reply to#1694364
On Sun, 2017-07-23 at 16:14 -0700, Linus Torvalds wrote:
> On Sun, Jul 23, 2017 at 1:00 PM, Linus Torvalds
> <torvalds@linux-foundation.org> 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 = \&by_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");
+	    }
+	}
     }
 }
 

[toc] | [prev] | [next] | [standalone]

#1698429

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2017-07-28 04:50 +0200
Message-ID<u83vI-6cn-11@gated-at.bofh.it>
In reply to#1698384
On Thu, Jul 27, 2017 at 5:30 PM, Joe Perches <joe@perches.com> 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

[toc] | [prev] | [next] | [standalone]

#1698437

FromJoe Perches <joe@perches.com>
Date2017-07-28 05:20 +0200
Message-ID<u83YJ-6Cu-7@gated-at.bofh.it>
In reply to#1698429
On Thu, 2017-07-27 at 19:43 -0700, Linus Torvalds wrote:
> On Thu, Jul 27, 2017 at 5:30 PM, Joe Perches <joe@perches.com> 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 <tree>/MAINTAINERS/<files> 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.

[toc] | [prev] | [next] | [standalone]

#1699138

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2017-07-29 00:40 +0200
Message-ID<u8m5j-1tQ-13@gated-at.bofh.it>
In reply to#1698437
On Thu, Jul 27, 2017 at 8:12 PM, Joe Perches <joe@perches.com> wrote:
>
> I think it's better to centralize the MAINTAINERS
> location in <tree>/MAINTAINERS/<files> 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: iommu@lists.linux-foundation.org
      5 L: keyrings@vger.kernel.org
      5 L: linux-block@vger.kernel.org
      6 L: linux-arm-msm@vger.kernel.org
      6 L: linux-samsung-soc@vger.kernel.org
      7 L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
      7 L: linux-security-module@vger.kernel.org
      7 L: linux-wpan@vger.kernel.org
      8 L: linux-acpi@vger.kernel.org
      8 L: linux-fsdevel@vger.kernel.org
      8 L: linux-ide@vger.kernel.org
      8 L: linux-serial@vger.kernel.org
      8 L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
      9 L: adi-buildroot-devel@lists.sourceforge.net (moderated for
non-subscribers)
      9 L: linux-hams@vger.kernel.org
      9 L: linux-mm@kvack.org
     11 L: kvm@vger.kernel.org
     11 L: linux-mmc@vger.kernel.org
     12 L: virtualization@lists.linux-foundation.org
     13 L: linux-renesas-soc@vger.kernel.org
     13 L: linux-s390@vger.kernel.org
     16 L: linux-iio@vger.kernel.org
     16 L: linux-mips@linux-mips.org
     17 L: linux-gpio@vger.kernel.org
     18 L: linux-crypto@vger.kernel.org
     18 L: linux-mtd@lists.infradead.org
     20 L: linux-arm-kernel@lists.infradead.org
     20 L: linux-input@vger.kernel.org
     22 L: linux-i2c@vger.kernel.org
     23 L: linux-edac@vger.kernel.org
     23 L: linux-fbdev@vger.kernel.org
     23 L: linux-rdma@vger.kernel.org
     25 L: linux-omap@vger.kernel.org
     26 L: alsa-devel@alsa-project.org (moderated for non-subscribers)
     27 L: linux-pm@vger.kernel.org
     28 L: dri-devel@lists.freedesktop.org
     29 L: linuxppc-dev@lists.ozlabs.org
     33 L: linux-pci@vger.kernel.org
     35 L: platform-driver-x86@vger.kernel.org
     39 L: linux-usb@vger.kernel.org
     44 L: linux-wireless@vger.kernel.org
     46 L: linux-hwmon@vger.kernel.org
     54 L: linux-kernel@vger.kernel.org
     57 L: linux-scsi@vger.kernel.org
    122 L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
    134 L: netdev@vger.kernel.org
    187 L: linux-media@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

[toc] | [prev] | [next] | [standalone]

#1699198

FromJoe Perches <joe@perches.com>
Date2017-07-29 03:10 +0200
Message-ID<u8oqu-3ee-7@gated-at.bofh.it>
In reply to#1699138
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-acpi@vger.kernel.org
L:	devel@acpica.org
ALTERA TRIPLE SPEED ETHERNET DRIVER
L:	netdev@vger.kernel.org
L:	nios2-dev@lists.rocketboards.org (moderated for non-subscribers)
ALTERA UART/JTAG UART SERIAL DRIVERS
L:	linux-serial@vger.kernel.org
L:	nios2-dev@lists.rocketboards.org (moderated for non-subscribers)
ANALOG DEVICES INC ASOC DRIVERS
L:	adi-buildroot-devel@lists.sourceforge.net (moderated for non-subscribers)
L:	alsa-devel@alsa-project.org (moderated for non-subscribers)
AOA (Apple Onboard Audio) ALSA DRIVER
L:	linuxppc-dev@lists.ozlabs.org
L:	alsa-devel@alsa-project.org (moderated for non-subscribers)
ARM/Amlogic Meson SoC support
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-amlogic@lists.infradead.org
ARM/ASPEED I2C DRIVER
L:	linux-i2c@vger.kernel.org
L:	openbmc@lists.ozlabs.org
ARM/IGEP MACHINE SUPPORT
L:	linux-omap@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek RTC DRIVER
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-mediatek@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek SoC support
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-mediatek@lists.infradead.org (moderated for non-subscribers)
ARM/Mediatek USB3 PHY DRIVER
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-mediatek@lists.infradead.org (moderated for non-subscribers)
ARM/OXNAS platform support
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-oxnas@lists.tuxfamily.org (moderated for non-subscribers)
ARM/QUALCOMM SUPPORT
L:	linux-arm-msm@vger.kernel.org
L:	linux-soc@vger.kernel.org
ARM/Rockchip SoC support
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-rockchip@lists.infradead.org
ARM/SAMSUNG EXYNOS ARM ARCHITECTURES
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
L:	linux-arm-kernel@lists.infradead.org
L:	linux-media@vger.kernel.org
ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT
L:	linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
L:	linux-media@vger.kernel.org
ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
L:	linux-arm-kernel@lists.infradead.org
L:	linux-media@vger.kernel.org
ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
L:	linux-arm-kernel@lists.infradead.org
L:	linux-media@vger.kernel.org
ARM/TEXAS INSTRUMENT KEYSTONE ClOCKSOURCE
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-kernel@vger.kernel.org
ASUS NOTEBOOKS AND EEEPC ACPI/WMI EXTRAS DRIVERS
L:	acpi4asus-user@lists.sourceforge.net
L:	platform-driver-x86@vger.kernel.org
ATM
L:	linux-atm-general@lists.sourceforge.net (moderated for non-subscribers)
L:	netdev@vger.kernel.org
ATMEL XDMA DRIVER
L:	linux-arm-kernel@lists.infradead.org
L:	dmaengine@vger.kernel.org
B43 WIRELESS DRIVER
L:	linux-wireless@vger.kernel.org
L:	b43-dev@lists.infradead.org
B43LEGACY WIRELESS DRIVER
L:	linux-wireless@vger.kernel.org
L:	b43-dev@lists.infradead.org
BPF (Safe dynamic programs and tools)
L:	netdev@vger.kernel.org
L:	linux-kernel@vger.kernel.org
BROADCOM B53 ETHERNET SWITCH DRIVER
L:	netdev@vger.kernel.org
L:	openwrt-devel@lists.openwrt.org (subscribers-only)
BROADCOM BCM2835 ARM ARCHITECTURE
L:	linux-rpi-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER
L:	linux-wireless@vger.kernel.org
L:	brcm80211-dev-list.pdl@broadcom.com
BROADCOM STB NAND FLASH DRIVER
L:	linux-mtd@lists.infradead.org
L:	bcm-kernel-feedback-list@broadcom.com
BUS FREQUENCY DRIVER FOR SAMSUNG EXYNOS
L:	linux-pm@vger.kernel.org
L:	linux-samsung-soc@vger.kernel.org
CCREE ARM TRUSTZONE CRYPTOCELL 700 REE DRIVER
L:	linux-crypto@vger.kernel.org
L:	driverdev-devel@linuxdriverproject.org
CHINESE DOCUMENTATION
L:	xiyoulinuxkernelgroup@googlegroups.com (subscribers-only)
L:	linux-kernel@zh-kernel.org (moderated for non-subscribers)
COMMON INTERNET FILE SYSTEM (CIFS)
L:	linux-cifs@vger.kernel.org
L:	samba-technical@lists.samba.org (moderated for non-subscribers)
CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)
L:	cgroups@vger.kernel.org
L:	linux-mm@kvack.org
CPUIDLE DRIVER - ARM BIG LITTLE
L:	linux-pm@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org
CPUIDLE DRIVER - ARM EXYNOS
L:	linux-pm@vger.kernel.org
L:	linux-samsung-soc@vger.kernel.org
CX18 VIDEO4LINUX DRIVER
L:	ivtv-devel@ivtvdriver.org (subscribers-only)
L:	linux-media@vger.kernel.org
DMA BUFFER SHARING FRAMEWORK
L:	linux-media@vger.kernel.org
L:	dri-devel@lists.freedesktop.org
DRM DRIVER FOR MSM ADRENO GPU
L:	linux-arm-msm@vger.kernel.org
L:	dri-devel@lists.freedesktop.org
DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS
L:	dri-devel@lists.freedesktop.org
L:	nouveau@lists.freedesktop.org
DRM DRIVERS FOR AMLOGIC SOCS
L:	dri-devel@lists.freedesktop.org
L:	linux-amlogic@lists.infradead.org
DRM DRIVERS FOR NVIDIA TEGRA
L:	dri-devel@lists.freedesktop.org
L:	linux-tegra@vger.kernel.org
DRM DRIVERS FOR RENESAS
L:	dri-devel@lists.freedesktop.org
L:	linux-renesas-soc@vger.kernel.org
DRM DRIVERS FOR VIVANTE GPU IP
L:	etnaviv@lists.freedesktop.org
L:	dri-devel@lists.freedesktop.org
EDAC-CAVIUM
L:	linux-edac@vger.kernel.org
L:	linux-mips@linux-mips.org
ETHERNET BRIDGE
L:	bridge@lists.linux-foundation.org (moderated for non-subscribers)
L:	netdev@vger.kernel.org
Extended Verification Module (EVM)
L:	linux-ima-devel@lists.sourceforge.net
L:	linux-security-module@vger.kernel.org
FIREWIRE MEDIA DRIVERS (firedtv)
L:	linux-media@vger.kernel.org
L:	linux1394-devel@lists.sourceforge.net
FIREWIRE SBP-2 TARGET
L:	linux-scsi@vger.kernel.org
L:	target-devel@vger.kernel.org
FREESCALE I2C CPM DRIVER
L:	linuxppc-dev@lists.ozlabs.org
L:	linux-i2c@vger.kernel.org
FREESCALE IMX / MXC FRAMEBUFFER DRIVER
L:	linux-fbdev@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
FREESCALE QUICC ENGINE UCC ETHERNET DRIVER
L:	netdev@vger.kernel.org
L:	linuxppc-dev@lists.ozlabs.org
FREESCALE QUICC ENGINE UCC HDLC DRIVER
L:	netdev@vger.kernel.org
L:	linuxppc-dev@lists.ozlabs.org
FREESCALE SOC DRIVERS
L:	linuxppc-dev@lists.ozlabs.org
L:	linux-arm-kernel@lists.infradead.org
FREESCALE SOC FS_ENET DRIVER
L:	linuxppc-dev@lists.ozlabs.org
L:	netdev@vger.kernel.org
FREESCALE SOC SOUND DRIVERS
L:	alsa-devel@alsa-project.org (moderated for non-subscribers)
L:	linuxppc-dev@lists.ozlabs.org
FREESCALE USB PERIPHERAL DRIVERS
L:	linux-usb@vger.kernel.org
L:	linuxppc-dev@lists.ozlabs.org
GPIO ACPI SUPPORT
L:	linux-gpio@vger.kernel.org
L:	linux-acpi@vger.kernel.org
HEWLETT-PACKARD SMART ARRAY RAID DRIVER (hpsa)
L:	esc.storagedev@microsemi.com
L:	linux-scsi@vger.kernel.org
HEWLETT-PACKARD SMART CISS RAID DRIVER (cciss)
L:	esc.storagedev@microsemi.com
L:	linux-scsi@vger.kernel.org
HID SENSOR HUB DRIVERS
L:	linux-input@vger.kernel.org
L:	linux-iio@vger.kernel.org
I2C ACPI SUPPORT
L:	linux-i2c@vger.kernel.org
L:	linux-acpi@vger.kernel.org
IBM Power Virtual SCSI Device Target Driver
L:	linux-scsi@vger.kernel.org
L:	target-devel@vger.kernel.org
INTEGRITY MEASUREMENT ARCHITECTURE (IMA)
L:	linux-ima-devel@lists.sourceforge.net
L:	linux-ima-user@lists.sourceforge.net
INTEL GVT-g DRIVERS (Intel GPU Virtualization)
L:	intel-gvt-dev@lists.freedesktop.org
L:	intel-gfx@lists.freedesktop.org
IPVS
L:	netdev@vger.kernel.org
L:	lvs-devel@vger.kernel.org
IRDA SUBSYSTEM
L:	irda-users@lists.sourceforge.net (subscribers-only)
L:	netdev@vger.kernel.org
ISCSI EXTENSIONS FOR RDMA (ISER) TARGET
L:	linux-rdma@vger.kernel.org
L:	target-devel@vger.kernel.org
ISDN SUBSYSTEM
L:	isdn4linux@listserv.isdn4linux.de (subscribers-only)
L:	netdev@vger.kernel.org
IVTV VIDEO4LINUX DRIVER
L:	ivtv-devel@ivtvdriver.org (subscribers-only)
L:	linux-media@vger.kernel.org
KERNEL VIRTUAL MACHINE (KVM) FOR ARM
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	kvmarm@lists.cs.columbia.edu
KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	kvmarm@lists.cs.columbia.edu
KEYS-ENCRYPTED
L:	linux-security-module@vger.kernel.org
L:	keyrings@vger.kernel.org
KEYS-TRUSTED
L:	linux-security-module@vger.kernel.org
L:	keyrings@vger.kernel.org
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
L:	MPT-FusionLinux.pdl@broadcom.com
L:	linux-scsi@vger.kernel.org
MEDIA DRIVERS FOR RENESAS - DRIF
L:	linux-media@vger.kernel.org
L:	linux-renesas-soc@vger.kernel.org
MEDIA DRIVERS FOR RENESAS - FCP
L:	linux-media@vger.kernel.org
L:	linux-renesas-soc@vger.kernel.org
MEDIA DRIVERS FOR RENESAS - FDP1
L:	linux-media@vger.kernel.org
L:	linux-renesas-soc@vger.kernel.org
MEDIA DRIVERS FOR RENESAS - VIN
L:	linux-media@vger.kernel.org
L:	linux-renesas-soc@vger.kernel.org
MEDIA DRIVERS FOR RENESAS - VSP1
L:	linux-media@vger.kernel.org
L:	linux-renesas-soc@vger.kernel.org
MEGARAID SCSI/SAS DRIVERS
L:	megaraidlinux.pdl@broadcom.com
L:	linux-scsi@vger.kernel.org
MELLANOX MLX4 core VPI driver
L:	netdev@vger.kernel.org
L:	linux-rdma@vger.kernel.org
MELLANOX MLX5 core VPI driver
L:	netdev@vger.kernel.org
L:	linux-rdma@vger.kernel.org
MICROCHIP / ATMEL DMA DRIVER
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	dmaengine@vger.kernel.org
MICROSEMI SMART ARRAY SMARTPQI DRIVER (smartpqi)
L:	esc.storagedev@microsemi.com
L:	linux-scsi@vger.kernel.org
NETFILTER
L:	netfilter-devel@vger.kernel.org
L:	coreteam@netfilter.org
NETWORK BLOCK DEVICE (NBD)
L:	linux-block@vger.kernel.org
L:	nbd-general@lists.sourceforge.net
NFC SUBSYSTEM
L:	linux-wireless@vger.kernel.org
L:	linux-nfc@lists.01.org (subscribers-only)
OMAP AUDIO SUPPORT
L:	alsa-devel@alsa-project.org (moderated for non-subscribers)
L:	linux-omap@vger.kernel.org
OMAP DEVICE TREE SUPPORT
L:	linux-omap@vger.kernel.org
L:	devicetree@vger.kernel.org
OMAP DISPLAY SUBSYSTEM and FRAMEBUFFER SUPPORT (DSS2)
L:	linux-omap@vger.kernel.org
L:	linux-fbdev@vger.kernel.org
OMAP FRAMEBUFFER SUPPORT
L:	linux-fbdev@vger.kernel.org
L:	linux-omap@vger.kernel.org
OMAP HS MMC SUPPORT
L:	linux-mmc@vger.kernel.org
L:	linux-omap@vger.kernel.org
OMAP USB SUPPORT
L:	linux-usb@vger.kernel.org
L:	linux-omap@vger.kernel.org
ONSTREAM SCSI TAPE DRIVER
L:	osst-users@lists.sourceforge.net
L:	linux-scsi@vger.kernel.org
OPENVSWITCH
L:	netdev@vger.kernel.org
L:	dev@openvswitch.org
PCI DRIVER FOR AARDVARK (Marvell Armada 3700)
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
PCI DRIVER FOR ALTERA PCIE IP
L:	rfi@lists.rocketboards.org (moderated for non-subscribers)
L:	linux-pci@vger.kernel.org
PCI DRIVER FOR APPLIEDMICRO XGENE
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org
PCI DRIVER FOR ARM VERSATILE PLATFORM
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org
PCI DRIVER FOR ARMADA 8K
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org
PCI DRIVER FOR FREESCALE LAYERSCAPE
L:	linuxppc-dev@lists.ozlabs.org
L:	linux-pci@vger.kernel.org
PCI DRIVER FOR GENERIC OF HOSTS
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
PCI DRIVER FOR IMX6
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
PCI DRIVER FOR MVEBU (Marvell Armada 370 and Armada XP SOC support)
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
PCI DRIVER FOR NVIDIA TEGRA
L:	linux-tegra@vger.kernel.org
L:	linux-pci@vger.kernel.org
PCI DRIVER FOR RENESAS R-CAR
L:	linux-pci@vger.kernel.org
L:	linux-renesas-soc@vger.kernel.org
PCI DRIVER FOR SAMSUNG EXYNOS
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
PCI DRIVER FOR TI DRA7XX
L:	linux-omap@vger.kernel.org
L:	linux-pci@vger.kernel.org
PCI DRIVER FOR TI KEYSTONE
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
PCI MSI DRIVER FOR ALTERA MSI IP
L:	rfi@lists.rocketboards.org (moderated for non-subscribers)
L:	linux-pci@vger.kernel.org
PCI MSI DRIVER FOR APPLIEDMICRO XGENE
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org
PCIE DRIVER FOR AXIS ARTPEC
L:	linux-arm-kernel@axis.com
L:	linux-pci@vger.kernel.org
PCIE DRIVER FOR CAVIUM THUNDERX
L:	linux-pci@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
PCIE DRIVER FOR MEDIATEK
L:	linux-pci@vger.kernel.org
L:	linux-mediatek@lists.infradead.org
PCIE DRIVER FOR QUALCOMM MSM
L:	linux-pci@vger.kernel.org
L:	linux-arm-msm@vger.kernel.org
PCIE DRIVER FOR ROCKCHIP
L:	linux-pci@vger.kernel.org
L:	linux-rockchip@lists.infradead.org
PIN CONTROLLER - ATMEL AT91 PIO4
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-gpio@vger.kernel.org
PIN CONTROLLER - SAMSUNG
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
PIN CONTROLLER - SINGLE
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L:	linux-omap@vger.kernel.org
PROC SYSCTL
L:	linux-kernel@vger.kernel.org
L:	linux-fsdevel@vger.kernel.org
PS3 NETWORK SUPPORT
L:	netdev@vger.kernel.org
L:	linuxppc-dev@lists.ozlabs.org
PVRUSB2 VIDEO4LINUX DRIVER
L:	pvrusb2@isely.net	(subscribers-only)
L:	linux-media@vger.kernel.org
QUALCOMM VENUS VIDEO ACCELERATOR DRIVER
L:	linux-media@vger.kernel.org
L:	linux-arm-msm@vger.kernel.org
RDS - RELIABLE DATAGRAM SOCKETS
L:	netdev@vger.kernel.org
L:	linux-rdma@vger.kernel.org
RENESAS ETHERNET DRIVERS
L:	netdev@vger.kernel.org
L:	linux-renesas-soc@vger.kernel.org
S390 VFIO-CCW DRIVER
L:	linux-s390@vger.kernel.org
L:	kvm@vger.kernel.org
SAMSUNG EXYNOS PSEUDO RANDOM NUMBER GENERATOR (RNG) DRIVER
L:	linux-crypto@vger.kernel.org
L:	linux-samsung-soc@vger.kernel.org
SAMSUNG MULTIFUNCTION PMIC DEVICE DRIVERS
L:	linux-kernel@vger.kernel.org
L:	linux-samsung-soc@vger.kernel.org
SAMSUNG S3C24XX/S3C64XX SOC SERIES CAMIF DRIVER
L:	linux-media@vger.kernel.org
L:	linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
SAMSUNG S5P Security SubSystem (SSS) DRIVER
L:	linux-crypto@vger.kernel.org
L:	linux-samsung-soc@vger.kernel.org
SAMSUNG SPI DRIVERS
L:	linux-spi@vger.kernel.org
L:	linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
SAMSUNG THERMAL DRIVER
L:	linux-pm@vger.kernel.org
L:	linux-samsung-soc@vger.kernel.org
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) Broadcom BRCMSTB DRIVER
L:	linux-mmc@vger.kernel.org
L:	bcm-kernel-feedback-list@broadcom.com
SILEAD TOUCHSCREEN DRIVER
L:	linux-input@vger.kernel.org
L:	platform-driver-x86@vger.kernel.org
STAGING - NVIDIA COMPLIANT EMBEDDED CONTROLLER INTERFACE (nvec)
L:	ac100@lists.launchpad.net (moderated for non-subscribers)
L:	linux-tegra@vger.kernel.org
SYNC FILE FRAMEWORK
L:	linux-media@vger.kernel.org
L:	dri-devel@lists.freedesktop.org
TARGET SUBSYSTEM
L:	linux-scsi@vger.kernel.org
L:	target-devel@vger.kernel.org
THINKPAD ACPI EXTRAS DRIVER
L:	ibm-acpi-devel@lists.sourceforge.net
L:	platform-driver-x86@vger.kernel.org
TI BANDGAP AND THERMAL DRIVER
L:	linux-pm@vger.kernel.org
L:	linux-omap@vger.kernel.org
TI ETHERNET SWITCH DRIVER (CPSW)
L:	linux-omap@vger.kernel.org
L:	netdev@vger.kernel.org
TI KEYSTONE MULTICORE NAVIGATOR DRIVERS
L:	linux-kernel@vger.kernel.org
L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
TI TRF7970A NFC DRIVER
L:	linux-wireless@vger.kernel.org
L:	linux-nfc@lists.01.org (moderated for non-subscribers)
TIPC NETWORK LAYER
L:	netdev@vger.kernel.org (core kernel code)
L:	tipc-discussion@lists.sourceforge.net (user apps, general discussion)
TOMOYO SECURITY MODULE
L:	tomoyo-dev-en@lists.sourceforge.jp (subscribers-only, for developers in English)
L:	tomoyo-users-en@lists.sourceforge.jp (subscribers-only, for users in English)
L:	tomoyo-dev@lists.sourceforge.jp (subscribers-only, for developers in Japanese)
L:	tomoyo-users@lists.sourceforge.jp (subscribers-only, for users in Japanese)
TRACING MMIO ACCESSES (MMIOTRACE)
L:	linux-kernel@vger.kernel.org
L:	nouveau@lists.freedesktop.org
TULIP NETWORK DRIVERS
L:	netdev@vger.kernel.org
L:	linux-parisc@vger.kernel.org
UCLINUX (M68KNOMMU AND COLDFIRE)
L:	linux-m68k@lists.linux-m68k.org
L:	uclinux-dev@uclinux.org  (subscribers-only)
USB ATTACHED SCSI
L:	linux-usb@vger.kernel.org
L:	linux-scsi@vger.kernel.org
USB MASS STORAGE DRIVER
L:	linux-usb@vger.kernel.org
L:	usb-storage@lists.one-eyed-alien.net
USB PEGASUS DRIVER
L:	linux-usb@vger.kernel.org
L:	netdev@vger.kernel.org
USB RTL8150 DRIVER
L:	linux-usb@vger.kernel.org
L:	netdev@vger.kernel.org
USB VIDEO CLASS
L:	linux-uvc-devel@lists.sourceforge.net (subscribers-only)
L:	linux-media@vger.kernel.org
USB ZR364XX DRIVER
L:	linux-usb@vger.kernel.org
L:	linux-media@vger.kernel.org
USER-MODE LINUX (UML)
L:	user-mode-linux-devel@lists.sourceforge.net
L:	user-mode-linux-user@lists.sourceforge.net
VIRTIO AND VHOST VSOCK DRIVER
L:	kvm@vger.kernel.org
L:	virtualization@lists.linux-foundation.org
VIRTIO CRYPTO DRIVER
L:	virtualization@lists.linux-foundation.org
L:	linux-crypto@vger.kernel.org
VIRTIO DRIVERS FOR S390
L:	linux-s390@vger.kernel.org
L:	virtualization@lists.linux-foundation.org
VIRTIO GPU DRIVER
L:	dri-devel@lists.freedesktop.org
L:	virtualization@lists.linux-foundation.org
VIRTIO HOST (VHOST)
L:	kvm@vger.kernel.org
L:	virtualization@lists.linux-foundation.org
VUB300 USB to SDIO/SD/MMC bridge chip
L:	linux-mmc@vger.kernel.org
L:	linux-usb@vger.kernel.org
WILOCITY WIL6210 WIRELESS DRIVER
L:	linux-wireless@vger.kernel.org
L:	wil6210@qca.qualcomm.com
XEN NETWORK BACKEND DRIVER
L:	xen-devel@lists.xenproject.org (moderated for non-subscribers)
L:	netdev@vger.kernel.org
XEN PVSCSI DRIVERS
L:	xen-devel@lists.xenproject.org (moderated for non-subscribers)
L:	linux-scsi@vger.kernel.org
ZD1211RW WIRELESS DRIVER
L:	linux-wireless@vger.kernel.org
L:	zd1211-devs@lists.sourceforge.net (subscribers-only)
ZR36067 VIDEO FOR LINUX DRIVER
L:	mjpeg-users@lists.sourceforge.net
L:	linux-media@vger.kernel.org

[toc] | [prev] | [next] | [standalone]

#1699339

FromJoe Perches <joe@perches.com>
Date2017-07-29 19:50 +0200
Message-ID<u8E2d-5z4-1@gated-at.bofh.it>
In reply to#1699138
On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote:
> On Thu, Jul 27, 2017 at 8:12 PM, Joe Perches <joe@perches.com> wrote:
> > 
> > I think it's better to centralize the MAINTAINERS
> > location in <tree>/MAINTAINERS/<files> 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.

[toc] | [prev] | [next] | [standalone]

#1694353

FromJoe Perches <joe@perches.com>
Date2017-07-23 22:10 +0200
Message-ID<u6vmp-3Au-9@gated-at.bofh.it>
In reply to#1694351
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 <lho@apm.com>
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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web