lkml.org 
[lkml]   [2008]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-10-01 01:43    [W:1.223 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site