linux-kernel - Re: [RFC] is it time to split up the MAINTAINERS file?

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: <1370934825.22004.21.camel@joe-AO722>
Date:	Tue, 11 Jun 2013 00:13:45 -0700
From:	Joe Perches <joe@...ches.com>
To:	Rob Landley <rob@...dley.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] is it time to split up the MAINTAINERS file?

On Mon, 2013-06-10 at 23:49 -0500, Rob Landley wrote:
> Quite possibly the answer is "no", but the MAINTAINERS file is  
> approaching 10,000 lines. Getting a bit unwieldy.

I think it hasn't been much of a bottleneck problem.

> The question is: would this be an improvement? (And worth the changes  
> to checkpatch.pl and such required to make it work?)

shrug.

MAINTAINERS is still the most frequently updated file.
This division eliminates those changes.

> One potential _advantage_ of this is we could make the reporting  
> hierarchy more explicit. The first entry in arch/arm/MAINTAINERS would  
> be the arm maintainer and everybody else _under_ there goes through  
> him. (Also, that guy could handle updates to the local MAINTAINERS file  
> itself, so we're not always spamming Andrew. Such updates could even  
> post to the architecture-specific list rather than linux-kernel.)

MAINTAINERS updates aren't centralized.
There are lots of MAINTAINERS updates from sub-maintainers.

> Yeah, reality isn't neatly nested. Lots of things refer to include  
> files and Documentation files, but there's generally a main area of  
> focus (where's the actual _code_?), and when you do have something like:
> 
> ARM/SHMOBILE ARM ARCHITECTURE
> M:      Simon Horman <horms@...ge.net.au>
> M:      Magnus Damm <magnus.damm@...il.com>
> L:      linux-sh@...r.kernel.org
> W:      http://oss.renesas.com
> Q:      http://patchwork.kernel.org/project/linux-sh/list/
> T:      git  
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git next
> S:      Supported
> F:      arch/arm/mach-shmobile/
> F:      drivers/sh/
> 
> 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...

Sprinkling a few hundred MAINTAINER styles files
around the tree would be the biggest negative.

But paths and files could be relative and absolute

F:	./			(everything at this directory and lower)
F:	./foo.c			(single file)
F:	Documentation/foo.txt	(absolute single file)

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)

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.

Still, I think the "best" approach would be to enhance
git to manage this additional information instead.

Something akin to:
https://lkml.org/lkml/2007/8/14/256

Maybe some standardization of "git notes" or
"git annotate" might work.

A script could be written to create something like the
existing MAINTAINERS file from that too.

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