Re: [RFC] How to (automatically) find the correct maintainer(s)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Matthias Schniedermeyer wrote:

Richard Knutsson wrote:

Stefan Richter wrote:


On 15 Jan, Matthias Schniedermeyer wrote:

Stefan Richter wrote:

On 14 Jan, Richard Knutsson wrote:

(Really liked the idea to have a "Maintainer"-button next to "Help"
in *config)

Rhetorical question: What will this button be used for?

Having "all(tm)" information of something in one place?

Or, "click here to say 'it does not work'"?

My rhetorical question wasn't about what it is intended for, but what
people would think it was intended for if it was there.


I think it could be practical to have an easy access to whom is
responsible for a driver and which mailinglist its development is
addressed to, both for people interested in helping develop the driver
and those who got an error (or fan-mail :).


I think adding the Maintainers-data is more or less a logical next step.

It's not always clear from the MAINTAINERS-file who is the right person
for what. Especially as it is a rather large text-file with only
mediocre search-friendlieness. It's a 3.5 K-lines file!

So when you know that you have a problem with drivers X, wouldn't it be
great if you could just "go to" the driver in *config and see not only
the Help-Text but the Maintainers-Data also.

Seems more like what you actually want to have there is links to users'
mailinglists or forums.

When this thread started, it was about assisting authors in submitting
patches.


Yes, this is a bit out of scope, but just realized a simple way to
implement it if using the CONFIG_FLAG-approach, just "grep" after the
flag, under which the user hit the "Maintainer"-button, in the
MAINTAINER-file. Also, I think this solves the handler-problem since an
entry can have multiple CONFIG_FLAG's stated.

I don't think we should add the maintainer-entries directly in Kconfig,
as you Stefan stated, because it is for configure the kernel. With the
above approach, it will just require minor fixes in the "make *config"
to handle it.


But how do you suppose the user gets the CONFIG_-String, which the user
then could for searching?

I'd say only a small percentage of hardcore-users would use the
.config-file directly, the others would deviate over *config, so i'd say
if the MAINTAINERS-data is integrated into Kconfig it's the perfect(tm)
90% solution.

OTOH you could just teach the *config to lookup a MAINTAINERS-entry when
all they are properly flagged.
Oh no, did'n mean like that. All entries in the Kconfig has a "config CONFIG_FLAG" (of course ;) ) and so *config "knows" which flag to search for (if added to MAINTAINERS, that is). 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux