linux-kernel - Re: [RFC] List of maintainers (draft #3)

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, 29 Sep 2008 19:56:25 +0200
From:	Pavel Machek <pavel@...e.cz>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Ben Dooks <ben-linux@...ff.org>,
	Uwe Kleine-K?nig <ukleinek@...len.de>,
	Denis Vlasenko <vda@...t.imtp.ilyichevsk.odessa.ua>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] List of maintainers (draft #3)

Hi!

>> Figuring out whom to send a patch to is not something you can automate
>> because it not only depends on what you're changing but *how* you're
>> changing it. The classic case being that whenever you change something
>> related to RCU that's non-trivial, you almost certainly want to CC
>> Paul "RCU" McKenney. But there's no *file* or *directory* pattern that
>> can automatically tell you this.
>>
>> Furthermore, if you're hacking on a specific part of the kernel, you
>> almost certainly are doing it wrong if you don't know who the relevant
>> maintainers are. For simple janitorial patches, you probably should
>> just work out the *top-level* maintainers (davem for networking, ingo
>> et al for x86, and so on) and send the patches to them. And when these
>> simple rules fail you, fall back to patch bombing Andrew.
>>
>
> This is, of course, true; however, there are people who should *always*  
> be included when touching specific files, and this *can* be automated.  
> This is particularly so when sending out cross-architectural patchsets.
>
> So no, automation isn't a substitute for intelligence, but that doesn't  
> mean that it can't be an *assistance*.
>
> We need this.  Right now too many people screw up even the part that  
> *can* be automated.

Yes please. Manually searching MAINTAINERS is  boring and hard... 'Is
it NETWORK BLOCK DEVICE' or 'NBD'? 'ALSA' or 'ADVANCED LINUX SOUND 
SYSTEM'? ... plus if you want subsystem maintainer, search tends to
give you about 179 individual driver maintainers, first.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/