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]
Message-ID: <20170720043607.e3xhccrxgdap4xbq@thunk.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ