linux-kernel - Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Jul 2017 20:54:18 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Joe Perches <joe@...ches.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

Joe Perches <joe@...ches.com> writes:

> On Wed, 2017-07-19 at 21:24 -0700, Linus Torvalds wrote:
>> On Wed, Jul 19, 2017 at 6:05 PM, Joe Perches <joe@...ches.com> wrote:
>> > 
>> > Just for ease of manipulation and not breaking the script much,
>> > I'd suggest just having a MAINTAINERS directory and stuffing
>> > each of the sections into separate files.
>> > 
>> > The script would only need to add $ cat MAINTAINERS/* as input.
>> 
>> So I don't mind the idea of just making MAINTAINERS a directory, but I
>> don't think we want to so far as to make one file per entry. That's
>> what, 1500+ files tiny files or so? Seems a bit excessive.
>> 
>> Maybe we can just do the prefix thing and just do 26 files A-Z
>> instead? Or maybe go by first word (so all the ARM things would go in
>> one place?)
>> 
>> A couple of hundred files sounds fine. A couple of thousand files
>> sound a bit excessive..
>
> $ ls MAINTAINERS.tmp/ | wc -l
> 1735
>
> <shrug>
>
> A couple thousand individual maintainers is also excessive.
>
> Most maintainers in MAINTAINERS aren't really much involved.
>
> A-Z is arbitrary and still difficult to find because it's
> not descriptive as to whatever is actually maintained.
>
> As a concept I think individual files would be better.
> But maybe grouping by subsystem instead of by letter.
>
> Maybe by mirroring the directory layouts.
>
> <by arch>
> drivers/net
> drivers/scsi

Or what about putting separate MAINTAINERS files in the hierarchy at
whichever level makes the most sense, ie. not too big and not too small.

eg.

arch/x86/MAINTAINERS
arch/arm64/MAINTAINERS
arch/powerpc/MAINTAINERS
...
net/MAINTAINERS
mm/MAINTAINERS
drivers/net/MAINTAINERS
drivers/media/MAINTAINERS
drivers/scsi/MAINTAINERS
drivers/gpu/drm/MAINTAINERS
drivers/MAINTAINERS

That way we might end up with 20-50 (?) files, but most of the conflicts
would be handled by a sub system maintainer before Linus sees them.

We might still need a top level file for "other", for things that really
don't fit anywhere.

Files would be allowed to have patterns that match elsewhere in the
tree, so eg. arch files could match against arch specific code in
drivers.

And you can still get the full list just with:

 $ find . -name MAINTAINERS | xargs ca

cheers