| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <45AABE8D.9010804@citd.de> Date: Mon, 15 Jan 2007 00:36:45 +0100 From: Matthias Schniedermeyer <ms@...d.de> To: Richard Knutsson <ricknu-0@...dent.ltu.se> Cc: linux-kernel@...r.kernel.org Subject: 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: <Initials/ShortenedName><Numbers> 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists