public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering
Date: Thu, 20 Jul 2017 09:48:15 -0700	[thread overview]
Message-ID: <1500569295.14415.14.camel@perches.com> (raw)
In-Reply-To: <87tw27gyzp.fsf@concordia.ellerman.id.au>

On Thu, 2017-07-20 at 20:54 +1000, Michael Ellerman wrote:
> Joe Perches <joe@perches.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@perches.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.

Same general concept, but then an expectation would be
relative paths for
filename patterns.

It's still hard to do when subsystem maintainers cross.
drivers/net vs drivers/net/ethernet/ vs drivers/net/wireless.
etc..

> 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.

  reply	other threads:[~2017-07-20 16:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-19 21:40 [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering Randy Dunlap
2017-07-19 21:44 ` Andrew Morton
2017-07-20  0:08   ` Linus Torvalds
2017-07-20  0:18     ` Randy Dunlap
2017-07-20  0:18     ` Linus Torvalds
2017-07-20  0:19     ` Randy Dunlap
2017-07-20  0:26       ` Linus Torvalds
2017-07-20  0:35         ` Linus Torvalds
2017-07-20  0:53           ` Linus Torvalds
2017-07-20  1:04             ` Randy Dunlap
2017-07-20  1:05     ` Joe Perches
2017-07-20  3:12       ` Joe Perches
2017-07-20  4:24       ` Linus Torvalds
2017-07-20  4:36         ` Theodore Ts'o
2017-07-20  4:53           ` Linus Torvalds
2017-07-20  4:43         ` Joe Perches
2017-07-20  4:57           ` Linus Torvalds
2017-07-20 10:54           ` Michael Ellerman
2017-07-20 16:48             ` Joe Perches [this message]
2017-07-20 18:03               ` Linus Torvalds
2017-07-20 22:50                 ` Joe Perches
2017-07-19 21:49 ` 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=1500569295.14415.14.camel@perches.com \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=rdunlap@infradead.org \
    --cc=torvalds@linux-foundation.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