LKML Archive on
help / color / mirror / Atom feed
From: Stefan Richter <>
To: Richard Knutsson <>
Subject: Re: [RFC] How to (automatically) find the correct maintainer(s)
Date: Sun, 14 Jan 2007 02:00:41 +0100 (CET)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 14 Jan, Richard Knutsson wrote:
> Stefan Richter wrote:
[getting a wrong contact from looking at the MAINTAINERS file]
> Hopefully, but I think it is asking much of the maintainer and then 
> there will certanly be confused/frustrated submitter who don't know why 
> they don't get any answer nor patched included. We have already seen a 
> few asking about what happened with their patches.

Sure. But such glitches occur due to lack of research by the submitter
or due to missing information about maintainers. Neither one would be
made worse nor cured by adding script-readable references to sources or
config options to the MAINTAINERS file.

>>> Can you make a object-file out of 2 c-files? Using Makefile?
>> Yes, you can, although I don't know if it is directly done in the
>> kernel build system.
> How?:
> gcc -c test.c test2.c -o test3.o
> gcc: cannot specify -o with -c or -S with multiple files
> (with only -c i got test.o and test2.o)

gcc -o test3.o test.c test.c

> In the kernel building system, an object-file is made from a c- or 
> s-file with the same name. Then, of course, they can be put together to 
> a larger object-file.
[multiple references in one maintainer record]
> What about possibility to replace it with:
> C:	IEEE1394*
> and use the same system as with the path-approach, "longest wins". (I 
> don't think just IEEE1394 is appropriate, since then there is 
> possibility with false-positives again)

I doubt that wildcards (or maybe regular expressions) are really needed.
But this can only be found out by going through some non-trivial cases.

>> On the other hand, we could write
>> F:	drivers/ieee1394
>> L:
>> P:	Ben and me
>> [...]
>> IEEE 1394 IPV4 DRIVER (eth1394)
>> F:	drivers/ieee1394/eth1394
>> [...]
>> If it was done the latter way, i.e. using F: not C:, it could be
>> made a rule that the more specific entries come after more generic
>> entries. Thus the last match of multiple matches is the proper one.
>> In any case, the longest match is the proper one.
> As I wrote in the initial mail, my first idea was like that. But how to 
> solve when different drivers (with of course different maintainers) lies 
> in the same directory?

To continue my above example:

F:	drivers/ieee1394/pcilynx

Should work. Note, the substrings "eth1394" and "pcilynx" do not denote
subdirectories. They are substrings of the paths to these drivers'
sources nonetheless.

> I thought something like include/linux/config.h,autoconf.h could be used 
> when referring to a few specific files in a directory. But there is also 
> the problem that all mails were the maintainer has no F: will fall in 
> the lap of the "good" maintainer with the shorter pathway, and I'm 
> afraid this might make people hesitant to add the F:.

1. The same can be said about the C: method, or about the status quo.
2. The patches will typically be Cced to the respective mailinglist
   where the driver maintainer can harvest the patch or can send an ACK
   or NAK as a signal to the subsystem maintainer whether to pick it up.
3. When people notice that patches are misdirected too often, they will
   update MAINTAINERS.

> It is just the problems with false-positives and picking out specific
> files that made me reconsider.

May I remind that whoever uses scripts to figure out contacts should
better double-check what the script found out for him. (Regardless
whether the script grepped for config options or for path components.)
There are carbon-based lifeforms on the receiving end.

BTW, it seems to me like the F: approach is easier than the C: one when
it comes to patches which touch only .h files. It is already somewhat
costly to backtrack .c files from .o files from config options, but
considerably more so with .h files.
Stefan Richter
-=====-=-=== ---= -===-

  reply	other threads:[~2007-01-14  1:01 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
2007-01-13 20:15     ` Stefan Richter
2007-01-13 23:33       ` Richard Knutsson
2007-01-14  1:00         ` Stefan Richter [this message]
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:

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

  git send-email \ \ \ \ \
    --subject='Re: [RFC] How to (automatically) find the correct maintainer(s)' \

* 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).