linux-kernel - Re: [RFC] automatic CC generation for patch submission

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: <468669AF.2030401@intel.com>
Date:	Sat, 30 Jun 2007 07:33:19 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Dan Aloni <da-x@...atomic.org>,
	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] automatic CC generation for patch submission

Andrew Morton wrote:
> On Fri, 29 Jun 2007 19:51:53 -0700 "Kok, Auke" <auke-jan.h.kok@...el.com> wrote:
> 
>>> Some extensions to the popular E-Mail clients might be needed 
>>> here. Also, a bot reading LKML would automatically send links 
>>> about posted patches to the other mailing lists whenever 
>>> someone forgets to add a CC.
>>>
>>> Any comments?
>> an easier way to implement this is to add an extra field in the MAINTAINERS 
>> file, something like below. All the contact info would stay the same, closely 
>> where applicable and it would allow you to also specify specific files as well.
> 
> We already have that information in git.  Parse the git changelogs of the
> affected files, find out who works on them.
> 
> Not that it'll help much, given the amnount of stuff which gets
> mysteriously ignored even when the correct people are cc'ed...
> 
> (For extra giggles we could parse emailed oops and bug reports and add the
> appropriate cc's there too.  Harder.)

well, I'm more thinking of the advertisement value of having some sort of 
pointer in the MAINTAINERS file to the exact location of a certain subsystem. 
Quite often I find myself searching somewhere in /drivers/ only to find out that 
the stuff I need is in asm/arch or elsewhere. E.g. alsa is a driver but lives in 
/sound/. Having a voluntary field (usable for other purposes) in the MAINTAINERS 
field seems awfully appropriate in that place and very low impact.

git does have that info, except for the fact that quite often others touch the 
same subsystem much more than the maintainer (pci, net, etc)...

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