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]

Message-ID: <46C1EE6F.2080807@gmail.com>
Date:	Tue, 14 Aug 2007 20:03:27 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Joe Perches <joe@...ches.com>
CC:	git@...r.kernel.org, Junio C Hamano <gitster@...ox.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Mariusz Kozlowski <m.kozlowski@...land.pl>,
	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/14/2007 07:00 PM, Joe Perches wrote:

> On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:

>> It isn't about MODULE_FOO() tags, it is about tagging /source/ files 
>> to help with putting CCs on patch submissals.
>> If we want to link source file foo.c and the 
>> MAINTAINERS information, we have 3 options:
>> 1. MAINTAINERS --> foo.c
>> 2. foo.c --> MAINTAINERS
>> 3. foo.c <--> some 3rd file <--> MAINTAINERS
> 
> I added git@...r.kernel.org and Junio Hamano

Well, yes, I agree -- going through GIT seems to be the only really workable 
solution.

That is, instead of (case 2, you snipped it) having a backlink to the 
MAINTAINERS file in a header inside the source GIT would maintain this 
backlink -- and at that point, you can basically forego the MAINTAINERS file 
completely other than as something GIT can generate and just regard all of 
it meta-information (you may want to generate MAINTAINERS for releases but 
making GIT the source is the idea).

"git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan 
Cox <alan@...>".

There are more possibilities for this kind of meta information. git info 
--author, git info --license, git info --whatever. Given that it's intended 
for developers, needing GIT should not get in the way but there's always the 
generated MAINTAINERS file in releases as well.

It would ofcourse automatically stay up to date through deleting and moving 
of files. You'd probably want to devise a way to enable a submitter to also 
automatically provide meta-information upon addition of files. This can be 
done in the same way as a "Signed-off-by". Just tags in a submit email.

This should probably turn out to be the way things work yes. The paths in 
the MAINTAINERS file grow stale, source headers might also and sticking 
headers on every source file isn't nice anyway -- it's meta-information and 
the SCM can maintain it.

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/