Messages in this thread | | | Date | Mon, 15 Jan 2007 19:01:33 +0100 | From | Richard Knutsson <> | Subject | Re: [RFC] How to (automatically) find the correct maintainer(s) |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |