Re: [RFC] How to (automatically) find the correct maintainer(s)
> On Sat, 13 Jan 2007 17:30:39 +0100 Richard Knutsson <[EMAIL PROTECTED]> wrote: > Would like to come with a suggestion I have been wondering about for a > while, why not add the config-flag, used in Kconfig/Makefile in the > MAINTAINERS-file? I find that the most practical way to find out who really maintains a driver is to run git-whatchanged on it and see who has been doing stuff to it. - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
On 15 Jan, Richard Knutsson was... > thinking of trying to implement it I'd say go ahead and test your idea. -- Stefan Richter -=-=-=== ---= - http://arcgraph.de/sr/ - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
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. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
Stefan Richter wrote: On 14 Jan, Richard Knutsson wrote: Stefan Richter wrote: May I remind that whoever uses scripts to figure out contacts should better double-check what the script found out for him. [...] During development, that's a given. But I would hope that when its more stable it will always find the right answer or no answer at all (if there is errors in ex MAINTAINERS, even the human will bother the receiver) Note, if people build scripts which look up contacts, I hope they don't become careless and forget to search elsewhere for proper contacts if _no_ contact was found automatically. Maybe the script may print out some pointers for such a case ;) [...] It is already somewhat costly to backtrack .c files from .o files from config options, but considerably more so with .h files. I think it is to early to be thinking about what is easier, first a "algorithm" that does what we want is needed, then I'm more then happy to write a script/program for it :) Costly?? It is even simple in bash: C_FILE=${O_FILE/'.o'/'.c'} When I wrote "somewhat costly" I didn't refer to a 1:1 mapping between .c and .o. That's not what it takes. I mostly referred to having to implement a parser for parts of the Linux Makefile language. On the bright side, the more indirection you introduce, the less people will write their own scripts and the less scripts with bugs will be out there. :-) Oh, yes so it is. But I don't think it will be too much. But do you have any objections on the last proposal (to include "I:"), otherwise I thinking of trying to implement it (thinking of Perl, any reason to not do so?) to see if it can stand real usage. Hope so (on bugs that is, always fun with scripts) :) [...] (I: for "include". Btw, what is F: standing for? Is it instead of P:?) [...] Doesn't need to be F. "Files" happens to start with F. Doh, was in the track of "pathway" or such... - 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/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] How to (automatically) find the correct maintainer(s)
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. > Help-Text and Dependencies/Selects are already there. Yes. For the purpose of configuring the kernel. > 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. > And you can place "Fallback"-Maintainers-Data on Tree-Parents, for the > cases where you only can pinpoint a area, like when you have a problem > with a USB-device. > > > I can ask a rhetorical question too: > Why not go back to Config.help. Having a huge X K-Lines file with > everything in one file can't be that bad. It worked before! I am in no way against Richard's plan to improve development and maintenance processes by easier access to contact data. -- Stefan Richter -=-=-=== ---= - http://arcgraph.de/sr/ - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
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? Help-Text and Dependencies/Selects are already there. 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. And you can place "Fallback"-Maintainers-Data on Tree-Parents, for the cases where you only can pinpoint a area, like when you have a problem with a USB-device. I can ask a rhetorical question too: Why not go back to Config.help. Having a huge X K-Lines file with everything in one file can't be that bad. It worked before! Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
Richard Knutsson wrote: > Matthias Schniedermeyer wrote: > >> Richard Knutsson wrote: >> >> >>> Matthias Schniedermeyer wrote: >>> >>> >>> Richard Knutsson wrote: > Any thoughts on this is very much appreciated (is there any flaws with > this?). > The thought that crossed my mind was: Why not do the same thing that was done to the "Help"-file. (Before it was superseded by Kconfig). Originaly there was a central Help-file, with all the texts. Then it was split and placed in each sub-dir. And later it was superseded by Kconfig. On the other hand you could skip the intermediate step and just fold the Maintainer-data directly into Kconfig, that way everything is "in one place" and you could place a "Maintainers"-Button next to the "Help"-Button in *config, or just display it alongside the help. And MAYBE that would also lessen the "update-to-date"-problem, as you can just write the MAINTAINERs-data when you create/update the Kconfig-file. Which is a thing that creates much bigger pain when you forget it accidently. ;-) Oh, and it neadly solves the mapping-problem, for at least all kernel-parts that have a Kconfig-option/Sub-Tree. >>> >>> I'm all for splitting up the MAINTAINERS! :) >>> >>> Just, do you have any ideas how to solve the possible multiple of the >>> same entries, when handling multiple sub-directories and when many >>> different drivers with different maintainers are in the same directory >>> and a maintainer have more then one driver? >>> >> >> >> Handles. >> If a Maintainer maintains several subsystems/drivers a "handle" could be >> used to references to a handle-list (hello MAINTAINERS) or to the place >> where the full-maintainers-entry is placed. >> > > Mm, and maybe store the entry on the shortest-pathway common directory. > Then there should be just a few left entries in the current MAINTAINERS. > But how to create the handles? > * Name (problem with persons with the same name) > * E-mail (much to change when they change it) > This also make a problem when there is a change of the maintainer, what > happens with the entry if there is no maintainer? > * Just numbers and increase every new one with one? (quite ugly!) > ... and here is the end of my ideas. > > Any good ideas? (Really liked the idea to have a "Maintainer"-button > next to "Help" in *config) I'd say something like: e.g. MS0001 MaSchn001 or something along that line. Some people have several entries in the MAINTAINERs and a new way would have to make that possible too. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
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? -- Stefan Richter -=-=-=== ---= -===- http://arcgraph.de/sr/ - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
On 14 Jan, Richard Knutsson wrote: > Stefan Richter wrote: >> gcc -o test3.o test.c test.c >> > That produces just an executable file with a misleading name :) #-) [...] >> 3. When people notice that patches are misdirected too often, they will >>update MAINTAINERS. >> > You mean they update other maintainers entries? That would be good... Strictly spoken, only Linus updates MAINTAINERS. Everybody else merely sends change requests which are forwarded or rejected. If newbie John Doe finds there is something missing in MAINTAINERS, he could send a proper patch *to the proper contacts*, et voilĂ . In short, people including John Doe updated MAINTAINERS. [...] >> May I remind that whoever uses scripts to figure out contacts should >> better double-check what the script found out for him. [...] > During development, that's a given. But I would hope that when its more > stable it will always find the right answer or no answer at all (if > there is errors in ex MAINTAINERS, even the human will bother the receiver) Note, if people build scripts which look up contacts, I hope they don't become careless and forget to search elsewhere for proper contacts if _no_ contact was found automatically. [...] >> It is already somewhat >> costly to backtrack .c files from .o files from config options, but >> considerably more so with .h files. >> > I think it is to early to be thinking about what is easier, first a > "algorithm" that does what we want is needed, then I'm more then happy > to write a script/program for it :) > Costly?? It is even simple in bash: > C_FILE=${O_FILE/'.o'/'.c'} When I wrote "somewhat costly" I didn't refer to a 1:1 mapping between .c and .o. That's not what it takes. I mostly referred to having to implement a parser for parts of the Linux Makefile language. On the bright side, the more indirection you introduce, the less people will write their own scripts and the less scripts with bugs will be out there. :-) [...] > (I: for "include". Btw, what is F: standing for? Is it instead of P:?) [...] Doesn't need to be F. "Files" happens to start with F. -- Stefan Richter -=-=-=== ---= -===- http://arcgraph.de/sr/ - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
Matthias Schniedermeyer wrote: Richard Knutsson wrote: Matthias Schniedermeyer wrote: Richard Knutsson wrote: Any thoughts on this is very much appreciated (is there any flaws with this?). The thought that crossed my mind was: Why not do the same thing that was done to the "Help"-file. (Before it was superseded by Kconfig). Originaly there was a central Help-file, with all the texts. Then it was split and placed in each sub-dir. And later it was superseded by Kconfig. On the other hand you could skip the intermediate step and just fold the Maintainer-data directly into Kconfig, that way everything is "in one place" and you could place a "Maintainers"-Button next to the "Help"-Button in *config, or just display it alongside the help. And MAYBE that would also lessen the "update-to-date"-problem, as you can just write the MAINTAINERs-data when you create/update the Kconfig-file. Which is a thing that creates much bigger pain when you forget it accidently. ;-) Oh, and it neadly solves the mapping-problem, for at least all kernel-parts that have a Kconfig-option/Sub-Tree. I'm all for splitting up the MAINTAINERS! :) Just, do you have any ideas how to solve the possible multiple of the same entries, when handling multiple sub-directories and when many different drivers with different maintainers are in the same directory and a maintainer have more then one driver? Handles. If a Maintainer maintains several subsystems/drivers a "handle" could be used to references to a handle-list (hello MAINTAINERS) or to the place where the full-maintainers-entry is placed. Mm, and maybe store the entry on the shortest-pathway common directory. Then there should be just a few left entries in the current MAINTAINERS. But how to create the handles? * Name (problem with persons with the same name) * E-mail (much to change when they change it) This also make a problem when there is a change of the maintainer, what happens with the entry if there is no maintainer? * Just numbers and increase every new one with one? (quite ugly!) ... and here is the end of my ideas. Any good ideas? (Really liked the idea to have a "Maintainer"-button next to "Help" in *config) - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
Stefan Richter wrote: 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. I suspect I have misunderstood your idea. Correct me if this is wrong: if you add: F: drivers/pci Then also the directories hotplug and pcie (and its content) will fall to that entry, unless there is someone adding: F: drivers/pci/hotplug in their entry. With the approach I suggested that is not possible (unless introducing wildcards). Also, a maintainer for the "hotplug" have to add: F: drivers/pci/hotplug F: drivers/pci/setup-bus or C: HOTPLUG and what will hinder it from including drivers/pci/hotplug/ other then adding the F: on PCI Hotplugs maintainer? (yes, this is no real problem since they probably are the same maintainer or just add the F: ) 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 That produces just an executable file with a misleading name :) (test with two files were neither has a 'main()') You need the '-c'-flag to tell the gcc just make them to object-files. 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. Mm, that is just a feature. Best to get the basics straighten out first :) On the other hand, we could write IEEE 1394 SUBSYSTEM F: drivers/ieee1394 L: [EMAIL PROTECTED] 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: IEEE 1394 PCILYNX DRIVER 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. Absolutely, also it can easily refer to the "include header-files" by: F: include/linux/pci.h which is not as easily done in "my" way. The local headers are ok I think as the c-files that includes it should have the same maintainer, but ex pci.h are used by _quite_ many drivers. But is the headers in the include/-directory just a matter for the maintainer since they are globally reachable. But I think this is _the_ downside of that approach. 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. No, since it is either a hit or it is not. Without wildcards, an entry like: C: CONFIG_IEEE1394 would not pick up ex CONFIG_IEEE1394_RAWIO. 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. You mean they update other maintainers entries? That would be good... [...] It is just the problems with false-positives and picking out spec
Re: [RFC] How to (automatically) find the correct maintainer(s)
I wrote: > gcc -o test3.o test.c test.c ^^ typo gcc -o test3.o test.c test2.c -- Stefan Richter -=-=-=== ---= -===- http://arcgraph.de/sr/ - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
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 >> >> IEEE 1394 SUBSYSTEM >> F: drivers/ieee1394 >> L: [EMAIL PROTECTED] >> 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: IEEE 1394 PCILYNX DRIVER 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 -=-=-=== ---= -===- http://arcgraph.de/sr/ - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
Richard Knutsson wrote: > Matthias Schniedermeyer wrote: > >> Richard Knutsson wrote: >> >> >> >>> Any thoughts on this is very much appreciated (is there any flaws with >>> this?). >>> >> >> >> The thought that crossed my mind was: >> >> Why not do the same thing that was done to the "Help"-file. (Before it >> was superseded by Kconfig). >> >> Originaly there was a central Help-file, with all the texts. Then it was >> split and placed in each sub-dir. And later it was superseded by Kconfig. >> >> On the other hand you could skip the intermediate step and just fold the >> Maintainer-data directly into Kconfig, that way everything is "in one >> place" and you could place a "Maintainers"-Button next to the >> "Help"-Button in *config, or just display it alongside the help. >> >> And MAYBE that would also lessen the "update-to-date"-problem, as you >> can just write the MAINTAINERs-data when you create/update the >> Kconfig-file. Which is a thing that creates much bigger pain when you >> forget it accidently. ;-) >> >> Oh, and it neadly solves the mapping-problem, for at least all >> kernel-parts that have a Kconfig-option/Sub-Tree. >> > > I'm all for splitting up the MAINTAINERS! :) > > Just, do you have any ideas how to solve the possible multiple of the > same entries, when handling multiple sub-directories and when many > different drivers with different maintainers are in the same directory > and a maintainer have more then one driver? Handles. If a Maintainer maintains several subsystems/drivers a "handle" could be used to references to a handle-list (hello MAINTAINERS) or to the place where the full-maintainers-entry is placed. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
Matthias Schniedermeyer wrote: Richard Knutsson wrote: Any thoughts on this is very much appreciated (is there any flaws with this?). The thought that crossed my mind was: Why not do the same thing that was done to the "Help"-file. (Before it was superseded by Kconfig). Originaly there was a central Help-file, with all the texts. Then it was split and placed in each sub-dir. And later it was superseded by Kconfig. On the other hand you could skip the intermediate step and just fold the Maintainer-data directly into Kconfig, that way everything is "in one place" and you could place a "Maintainers"-Button next to the "Help"-Button in *config, or just display it alongside the help. And MAYBE that would also lessen the "update-to-date"-problem, as you can just write the MAINTAINERs-data when you create/update the Kconfig-file. Which is a thing that creates much bigger pain when you forget it accidently. ;-) Oh, and it neadly solves the mapping-problem, for at least all kernel-parts that have a Kconfig-option/Sub-Tree. I'm all for splitting up the MAINTAINERS! :) Just, do you have any ideas how to solve the possible multiple of the same entries, when handling multiple sub-directories and when many different drivers with different maintainers are in the same directory and a maintainer have more then one driver? - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
Stefan Richter wrote: On 13 Jan, Richard Knutsson wrote: Stefan Richter wrote: On 13 Jan, Richard Knutsson wrote: [...] SUPERCOOL ALPHA CARD P: Clark Kent M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] 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? I believe you read too quickly what I wrote, didn't you? :-) The MAINTAINER file doesn't influence how drivers are built. What the... now I have no idea why I deleted the previous text... oh well, I tried 'grep -Er "^M\:" */*' but did not find any such entries. Or did you mean files just stating "I maintaining this file"? At least I know so much about the building-process that I don't think MAINTAINER is involved :). It was meant as: how is a driver build without some CONFIG_-flag set, but not sure now what I wanted with that (blaming low blood-suger, got a pizza since then). - 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. I am specifically thinking of drivers which are maintained by the subsystem maintainers. (Well, see below...) More then one subsystem maintainers that is maintainers to a driver? I would think one off those would quite naturally become the maintainer of the driver and then accepting patches from the rest. Besides, the subsystem maintainer could point the submitter to a more appropriate channel or ignore the submitter. (A submitter who feels ignored is hopefully doing some more research then.) Also, a driver maintainer certainly reads the mailinglist to which the submitter posted. 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. - 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? Yes, you can, although I don't know if it is directly done in the kernel build system. Of course what is often done is to make n object files out of n c files, then link them to make 1 object file. 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) 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. 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 :) ...OK, we /could/ write IEEE 1394 SUBSYSTEM C: IEEE1394 C: IEEE1394_OHCI1394 C: IEEE1394_SBP2 C: IEEE1394_DV1394 /* would better be put into a new own entry due to different status of maintenance level */ C: IEEE1394_VIDEO1394 /* that one perhaps too */ L: [EMAIL PROTECTED] P: Ben and me [...] IEEE 1394 IPV4 DRIVER (eth1394) C: IEEE1394_ETH1394 [...] 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) On the other hand, we could write IEEE 1394 SUBSYSTEM F: drivers/ieee1394 L: [EMAIL PROTECTED] 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 drive
Re: [RFC] How to (automatically) find the correct maintainer(s)
On 13 Jan, Richard Knutsson wrote: > Stefan Richter wrote: >> On 13 Jan, Richard Knutsson wrote: >> [...] >> >>> SUPERCOOL ALPHA CARD >>> >>> P: Clark Kent >>> M: [EMAIL PROTECTED] >>> L: [EMAIL PROTECTED] >>> 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? I believe you read too quickly what I wrote, didn't you? :-) The MAINTAINER file doesn't influence how drivers are built. >> - 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. I am specifically thinking of drivers which are maintained by the subsystem maintainers. (Well, see below...) Besides, the subsystem maintainer could point the submitter to a more appropriate channel or ignore the submitter. (A submitter who feels ignored is hopefully doing some more research then.) Also, a driver maintainer certainly reads the mailinglist to which the submitter posted. >> - 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? Yes, you can, although I don't know if it is directly done in the kernel build system. Of course what is often done is to make n object files out of n c files, then link them to make 1 object file. >> 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 :) ...OK, we /could/ write IEEE 1394 SUBSYSTEM C: IEEE1394 C: IEEE1394_OHCI1394 C: IEEE1394_SBP2 C: IEEE1394_DV1394 /* would better be put into a new own entry due to different status of maintenance level */ C: IEEE1394_VIDEO1394 /* that one perhaps too */ L: [EMAIL PROTECTED] P: Ben and me [...] IEEE 1394 IPV4 DRIVER (eth1394) C: IEEE1394_ETH1394 [...] On the other hand, we could write IEEE 1394 SUBSYSTEM F: drivers/ieee1394 L: [EMAIL PROTECTED] 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. > But what about ex ieee1394_core.o? Is ieee1394-objs "equal" to > ieee1394.o? (Seems I need to read some Makefile docs...) Yes and yes. (Documentation/kbuild/makefiles.txt) >> 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) No, it probably isn't. > (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). Your approach could give a wrong answer if someone implements a very "clever" mapping. My approach could give a wrong answer if someone takes a generic match while there was a more specific match. Your approach requires to evaluate the diffstat, one or more Makefile (taking the Linux Makefile syntax into account), and the MAINTAINERS file. My approach just requires to evaluate the diffstat and the MAINTAINERS file. -- Stefan Richter -=-=-=== ---= -==-= http://arcgraph.de/sr/ - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
Richard Knutsson wrote: > Any thoughts on this is very much appreciated (is there any flaws with > this?). The thought that crossed my mind was: Why not do the same thing that was done to the "Help"-file. (Before it was superseded by Kconfig). Originaly there was a central Help-file, with all the texts. Then it was split and placed in each sub-dir. And later it was superseded by Kconfig. On the other hand you could skip the intermediate step and just fold the Maintainer-data directly into Kconfig, that way everything is "in one place" and you could place a "Maintainers"-Button next to the "Help"-Button in *config, or just display it alongside the help. And MAYBE that would also lessen the "update-to-date"-problem, as you can just write the MAINTAINERs-data when you create/update the Kconfig-file. Which is a thing that creates much bigger pain when you forget it accidently. ;-) Oh, and it neadly solves the mapping-problem, for at least all kernel-parts that have a Kconfig-option/Sub-Tree. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
Stefan Richter wrote: On 13 Jan, Richard Knutsson wrote: [...] SUPERCOOL ALPHA CARD P: Clark Kent M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] 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! - 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/
Re: [RFC] How to (automatically) find the correct maintainer(s)
On 13 Jan, Richard Knutsson wrote: [...] > SUPERCOOL ALPHA CARD > > P:Clark Kent > M:[EMAIL PROTECTED] > L:[EMAIL PROTECTED] > 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? - What if these drivers depend on two subsystems? - Config options map to object files but do not map directly to source files. Diffstats show source files. 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? 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. -- Stefan Richter -=-=-=== ---= -==-= http://arcgraph.de/sr/ - 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/
[RFC] How to (automatically) find the correct maintainer(s)
Hello all Would like to come with a suggestion I have been wondering about for a while, why not add the config-flag, used in Kconfig/Makefile in the MAINTAINERS-file? By doing this, there would not be any confusion who to send a patch, since all "files" is defined under a flag, right? (when it is a header-file, it can be grep'ed on the c-files and from the hit find the flag) So, with a MAINTAINERS-entry like: SUPERCOOL ALPHA CARD P: Clark Kent M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] 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). And because there is no question how to find the correct maintainer, a script can do it for us. This is something that would be really useful for Kernel-Janitors when doing big cleanups all over the kernel (see ex pci_module_init to pci_register_driver and standardize the tree to use macros from include/linux/kernel.h). By this, I believe trivial patch-series would be reduced from the lkml when they can automatically be sent to the maintainer (and maybe specified mailing-list). 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?). Richard Knutsson - 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/