linux-kernel - Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch

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]

Date:	Mon, 13 Aug 2007 20:10:15 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Mariusz Kozlowski <m.kozlowski@...land.pl>,
	Joe Perches <joe@...ches.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch -	scripts/get_maintainer.pl

On 08/13/2007 07:42 PM, Arjan van de Ven wrote:

> On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:
>> Hello,
>>
>> 	I don't recall discusion about this so here are my 3 cents:
>>
>> 	I like the idea. 
> 
> I don't actually. It shows a central MAINTAINERS file is the wrong
> approach; just that 500+ patches to the same file were needed shows
> that. 

Quite.

> The maintainer info should be in the source file itself! That's the only 
> reasonable way to keep it updated; now I'm all for having it machine 
> parsable so that tools can use it, but it still really should be in the 
> code itself, not in some central file that will always just go out of 
> data, and will be a huge source of needless patch conflicts.

This is quite like the OO-INDEX discussion now going, where I saw it argued 
that the one-line summaries could go at the top of the actual Documentation 
files themselves, where they could be mechanically extracted to _build_ the 
index files. Keeping things in sync is the important reason there as well.

While the notion behing these patches appears to be good, the tree sees many 
changes through addition, removal and movement of files which affects this. 
Is Linus's copy of git going to check if an added file doesn't overlap with 
an existing wildcard in the MAINTAINERS file and delele or adjust wildcards 
upon removal or movement?

I personally think it wouldn't be such as bad idea to introduce a standard 
Linux source file header, with (when present) information such as the 
summary for index files, maintainer information, and other information now 
present in MAINTAINERS. With it being in the sourcefile themslves, it will 
stand a much better chance of staying up to date.

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