[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1370970619.2776.97@driftwood>
Date: Tue, 11 Jun 2013 12:10:19 -0500
From: Rob Landley <rob@...dley.net>
To: Joe Perches <joe@...ches.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [RFC] is it time to split up the MAINTAINERS file?
On 06/11/2013 02:13:45 AM, Joe Perches wrote:
> On Mon, 2013-06-10 at 23:49 -0500, Rob Landley wrote:
> > You could either have the same entry in more than one MAINTAINERS
> file
> > or keep it at a higher level. (This wouldn't eliminate the top level
> > MAINTAINERS, merely trim it down a bit.)
> >
> > Just throwing it out there. Seems like it might be a thing, someday
> > anyway...
>
> Patches talk...
So you suggest sending a patch series to break out arch directories and
go "here, a whole new task for you the architecture maintainer to take
on!" and that's the _polite_ way to ask whether or not it's a good idea?
> or add an initial / for the absolutes
>
> F: */ (everything at this directory and lower)
> F: foo.c (single file)
> F: /Documentation/foo.txt (absolute single file)
That one, obviously. (Optimize for the common case.)
> make could be taught to create an overall integrated
> MAINTAINERS, which would not be part of the files
> managed by git/cvs from these submaintainer files.
Why? (What's the point? Does it make finding who is in charge of $THING
easier?)
> Still, I think the "best" approach would be to enhance
> git to manage this additional information instead.
Oh please no.
> Something akin to:
> https://lkml.org/lkml/2007/8/14/256
I'm sorry I brought it up.
> Maybe some standardization of "git notes" or
> "git annotate" might work.
The horror! The horror!
> A script could be written to create something like the
> existing MAINTAINERS file from that too.
I won't mention it again.
*shudder*
Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists