LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Richard Knutsson <ricknu-0@student.ltu.se>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] How to (automatically) find the correct maintainer(s)
Date: Sat, 13 Jan 2007 20:18:01 +0100	[thread overview]
Message-ID: <45A93069.5080906@student.ltu.se> (raw)
In-Reply-To: <tkrat.428a51215926acac@s5r6.in-berlin.de>

Stefan Richter wrote:
> On 13 Jan, Richard Knutsson wrote:
> [...]
>   
>> SUPERCOOL ALPHA CARD
>>
>> P:	Clark Kent
>> M:	superman@krypton.kr
>> L:	some@thing.com
>> C:	SUPER_A
>> S:	Maintained
>> (C: for CONFIG. Any better idea?)
>>
>> then if someone changes a file who are built with CONFIG_SUPER_A, can 
>> easily backtrack it to the correct maintainer(s).
>>     
> [...]
>   
>> My first idea was to use the pathway and define that directories above 
>> the specified (if not specified by another) would fall to the current 
>> maintainer. It would work, but requires that all pathways be specified 
>> at once, or a few maintainers with "short" pathways would get much of 
>> the patches (and it is not as correct/easy to maintain as looking for 
>> the CONFIG_flag).
>>
>>
>> Any thoughts on this is very much appreciated (is there any flaws with 
>> this?).
>>     
>
>  - What about drivers which have no MAINTAINER entry but reside in a
>    subsystem with MAINTAINER entry?
>   
Hmm, how are those drivers built? Can you please point me to one?
>  - What if these drivers depend on two subsystems?
>   
Not sure if I understand the problem. I don't see the maintainers for 
the subsystems too interested in a driver, and it is the drivers 
maintainer we want.
>  
>  - Config options map to object files but do not map directly to source
>    files. Diffstats show source files.
>   
Can you make a object-file out of 2 c-files? Using Makefile?
> Example: The sbp2 driver is an IEEE 1394 driver and a SCSI driver.
> sbp2.o is enabled by CONFIG_IEEE1394_SBP2 which depends on
> CONFIG_IEEE1394 and CONFIG_SCSI. sbp2.c resides in drivers/ieee1394/.
> What is the algorithm to look up sbp2's maintainers?
>   
The one listed for CONFIG_IEEE1394_SBP2 :)

But what about ex ieee1394_core.o? Is ieee1394-objs "equal" to 
ieee1394.o? (Seems I need to read some Makefile docs...)
> Don't get me wrong though. Easier lookup of maintainers and mailinglists
> sounds to me like a desirable feature, not just from the point of view
> of submitters but also of maintainers.
>   
Well, as they say: "If it is too good to be true, it usually is" (but I 
don't think it is too far fetched)

(Btw, what I can see, there is no possibility to get the wrong 
maintainer. Just that sometime it can't give you an answer and you have 
to do it in the old way).

Thanks for all the pointers!

  reply	other threads:[~2007-01-13 19:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-13 16:30 Richard Knutsson
2007-01-13 17:16 ` Stefan Richter
2007-01-13 19:18   ` Richard Knutsson [this message]
2007-01-13 20:15     ` Stefan Richter
2007-01-13 23:33       ` Richard Knutsson
2007-01-14  1:00         ` Stefan Richter
2007-01-14  1:02           ` Stefan Richter
2007-01-14 21:28           ` Richard Knutsson
2007-01-14 22:44             ` Stefan Richter
2007-01-15 18:39               ` Richard Knutsson
2007-01-15 20:06                 ` Stefan Richter
2007-01-13 20:03 ` Matthias Schniedermeyer
2007-01-13 23:41   ` Richard Knutsson
2007-01-14  0:04     ` Matthias Schniedermeyer
2007-01-14 21:42       ` Richard Knutsson
2007-01-14 23:04         ` Stefan Richter
2007-01-15  0:01           ` Matthias Schniedermeyer
2007-01-15  0:43             ` Stefan Richter
2007-01-15 18:01               ` Richard Knutsson
2007-01-15 20:05                 ` Matthias Schniedermeyer
2007-01-15 20:21                   ` Richard Knutsson
2007-01-14 23:36         ` Matthias Schniedermeyer
2007-01-22 19:56 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45A93069.5080906@student.ltu.se \
    --to=ricknu-0@student.ltu.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    --subject='Re: [RFC] How to (automatically) find the correct maintainer(s)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).