All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Pavel Machek <pavel@ucw.cz>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2] get_maintainer: Prepare for separate MAINTAINERS files
Date: Mon, 14 Aug 2017 17:58:58 -0700	[thread overview]
Message-ID: <1502758738.8295.29.camel@perches.com> (raw)
In-Reply-To: <20170814220929.GA3937@amd>

On Tue, 2017-08-15 at 00:09 +0200, Pavel Machek wrote:
> Hi!
> 
> On Wed 2017-08-02 11:15:09, Linus Torvalds wrote:
> > On Wed, Aug 2, 2017 at 11:06 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
> > > 
> > > IMO, the parse-maintainters.pl (sorting) script makes the need for separate
> > > MAINTAINERS files much less important since the file can be "fixed" easily
> > > at any time.
> > 
> > For me it's not the "fixing". It's the inevitable merge mess, and the
> > two hundred commits that I have to go through.
> > 
> > That said, the extra time just to look for MAINTAINERS files makes me
> > unhappy. It may be just .3s on Joe's machine, but it's presumably much
> > more when things aren't in the filesystem caches. I (like apparently
> > Joe) have an SSD so it's not a big deal for me, but..
> > 
> > Just having a single MAINTAINERS directory would alleviate that
> > concern.
> 
> Well, I am one of those slow-spinning-rust users. (I do have SSD here,
> but bcache is not exactly easy to configure with already-existing
> setup).
> 
> Using git is already pretty painful... but I believe having
> net/MAINTAINERS file which clearly tells you who maintains this
> directory would save time even for me. Grepping MAINTAINERS is not
> currently very easy ("is it NET subsystem or NETWORK subsystem?", is
> it listed as "ALSA" or "ADVANCED LINUX SOUND..."?) and splitting it to
> directories would help a lot.
> 
> Having single directory with all the MAINTAINERS files would be even
> worse than current situation..

What does not work well about scripts/get_maintainer.pl ?

      reply	other threads:[~2017-08-15  0:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-23 20:32 [PATCH V2] get_maintainer: Prepare for separate MAINTAINERS files Joe Perches
2017-08-02  8:04 ` Joe Perches
2017-08-02 18:06   ` Randy Dunlap
2017-08-02 18:15     ` Linus Torvalds
2017-08-02 20:35       ` Joe Perches
2017-08-14 22:09       ` Pavel Machek
2017-08-15  0:58         ` Joe Perches [this message]

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=1502758738.8295.29.camel@perches.com \
    --to=joe@perches.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.