Messages in this thread | | | From | Linus Torvalds <> | Date | Fri, 28 Jul 2017 15:30:30 -0700 | Subject | Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering |
| |
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
| |