From: Linus Torvalds <torvalds@linux-foundation.org>
To: Joe Perches <joe@perches.com>
Cc: Randy Dunlap <rdunlap@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering
Date: Fri, 28 Jul 2017 15:30:30 -0700 [thread overview]
Message-ID: <CA+55aFzgHOnQ-Unfw=RSQ7myz0_twSNv9K+ebYFZcfjiVHkBtw@mail.gmail.com> (raw)
In-Reply-To: <1501211532.5368.42.camel@perches.com>
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
next prev parent reply other threads:[~2017-07-28 22:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 20:32 [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering Randy Dunlap
2017-07-22 2:01 ` Linus Torvalds
2017-07-23 19:49 ` Linus Torvalds
2017-07-23 20:00 ` Linus Torvalds
2017-07-23 20:10 ` Joe Perches
2017-07-23 23:14 ` Linus Torvalds
2017-07-24 1:38 ` Joe Perches
2017-07-28 0:30 ` Joe Perches
2017-07-28 2:43 ` Linus Torvalds
2017-07-28 3:12 ` Joe Perches
2017-07-28 22:30 ` Linus Torvalds [this message]
2017-07-29 1:08 ` Joe Perches
2017-07-29 17:46 ` Joe Perches
2017-07-23 20:05 ` Joe Perches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+55aFzgHOnQ-Unfw=RSQ7myz0_twSNv9K+ebYFZcfjiVHkBtw@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).