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 00:36:07 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Joe Perches <joe@...ches.com>,
        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

On Wed, Jul 19, 2017 at 09:24:13PM -0700, Linus Torvalds wrote:
> 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?)

Is that really going to help with merge conflicts?  It might help keep
things more in order, but if there is a merge conflict caused by two
changes to adjacent entries causing patch "fuzz", splitting things
into 26 files A-Z isn't going to significantly decrease the odds of
this happening.

It would seem to me that keeping a single file, and if we have a
program which sanity checks changes to the Maintainers format (warns
of missing required fields or unknown fields, or entries inserted out
of order, etc.) perhaps that would accomplish most of what we are looking for?

Or we could do something really hacky, like add "\n----\n" between
each entry to avoid merge conflicts caused by adjacent changes or
adjacent inserts?  But that's an idea that is probably too ugly to live...

	 	       	      	      	   - Ted