{"thread":{"id":"9556","subject":"Storing Maintainers info around the kernel tree","startedAt":"2007-08-16T13:04:50Z","lastAt":"2007-08-17T06:25:20Z","messageCount":9,"participants":["Kyle Moffett","Rene Herman","Alan Stern","Stefan Richter"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50884","messageId":"D31EF534-ACD1-426D-AF88-F152C23CB542@mac.com","threadId":"9556","inReplyTo":"200708151321.05959.rjw@sisk.pl","subject":"Storing Maintainers info around the kernel tree","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2007-08-16T13:04:50Z","receivedAt":"2007-08-16T13:04:50Z","isPatch":false,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"Merging a couple related threads here:\n\nOn Aug 16, 2007, at 07:57:23, Rene Herman wrote:\n> On 08/16/2007 01:26 PM, Salikh Zakirov wrote:\n>> Rene Herman wrote:\n>>> Perhaps that immediately suggests an implementation to someone  \n>>> already familiar with git internals?\n>> perhaps http://www.kernel.org/pub/software/scm/git/docs/ \n>> gitattributes.html and http://www.kernel.org/pub/software/scm/git/ \n>> docs/git-check-attr.html can help you?\n>\n> No, thanks, saw them, but .gitattributes is in fact in the same  \n> category as .gitignore, which would _be_ a property.\n>\n> If you do this stuff in files scattered around the tree, updating  \n> and moving stuff becomes a pain -- the tool would need to go edit  \n> files.\n\n From a practical standpoint we don't want to duplicate someone's  \nmaintainer information in the attributes of every file they  \nmaintain.  It would be much easier to put in the \"kernel/somesubsys\"  \ndirectory a Maintainers file which has:\n\n[SOME RANDOM SUBSYSTEM]\nP: J. Random Hacker\nM: j.random.hacker@localhost\nL: random-subsys-devel@vger.kernel.org\nF: *\n\nAnywhere else you had files that you wanted to associate with J.  \nRandom Hacker's maintainership, you would just use:\n\n[SOME RANDOM SUBSYSTEM]\nF: somesubsys.h\n\n\nI posted a comment describing a mechanism like this a couple days ago:\n   http://lkml.org/lkml/2007/8/14/488\n\nExecutive overview:\nOn Aug 15, 2007, at 07:21:04, Rafael J. Wysocki wrote:\n> On Wednesday, 15 August 2007 04:51, Kyle Moffett wrote:\n>> (a) \"Maintainers\" files sprinkled around the source tree with  \n>> relative pathnames and other data\n>>\n>> (b) Tool to generate a combined \"MAINTAINERS\" file from the ones  \n>> sprinkled around the source tree\n>>\n>> (c) Tool to search through the generated \"MAINTAINERS\" file with  \n>> all sorts of useful command-line options\n>>\n>> (d) Tool to check the generated \"MAINTAINERS\" file against recent  \n>> git history and make suggestions\n>\n> I like this idea. :-)\n\nWell, to back up this idea with some code, I'm attaching a little  \nperl script which does part (b).  Basically you call it as:\n   ./maint-combine $(find . -name Maintainers)\n\nIt will print any syntax errors on stderr during parsing.  Once it's  \ndone it will dump to stdout its combined \"MAINTAINERS\" text.  A  \ncouple notes:\n\n*  It uses a little \"priority\" system to figure out what order to  \nprint the data from each origin in.  For example, the \"F:\" tag is  \ngiven a score of 0, to force data consisting of just files towards  \nthe end.  The \"P:\", \"M:\", and \"L:\" tags are given scores of 5, since  \npeople are generally interesting to know about.  Everything else is  \ngiven a score of \"1\".  The scores are added up per ($file,  \n$subsystem) pair and then during printing each subsystem's data is  \nordered by score (highest comes first).\n\n*  It generally allows any field at all; eventually we might want to  \nlimit it to a fixed list to help avoid typos.\n\n*  It has a little bit of magic logic for the \"F:\" field so that it  \nfigures out the relative directory for each field when generating the  \noutput.  For example, an entry of \"asm-*/suspend.h\" in a file  \n\"include/Maintainers\" will produce the output file entry: \"F: include/ \nasm-*/suspend.h\"\n\n*  The format isn't quite the same as the current MAINTAINERS file,  \nto make parsing easier and more dummy-proof I changed the syntax for  \na subsystem-name to use square brackets (IE: \"[SUSPEND TO RAM]\").   \nThe samples I gave in my previous email are what I used to test it  \nwith, plus a little dummy file with some syntax errors to check out  \nthe error messages:\n\nMaintainers:\n> [EVERYTHING ELSE]\n> P: Various Linux Kernel Developers\n> L: linux-kernel@vger.kernel.org\n> F: *\n\nkernel/power/Maintainers:\n> [SUSPEND TO RAM]\n> P: Pavel Machek\n> M: pavel@suse.cz\n> P: Rafael J. Wysocki\n> M: rjw@sisk.pl\n> L: linux-pm@lists.linux-foundation.org\n> S: Maintained\n> F: *\n\ninclude/Maintainers:\n> [SUSPEND TO RAM]\n> F: linux/suspend.h\n> F: linux/freezer.h\n> F: linux/pm.h\n> F: asm-*/suspend.h\n\n\n\nIf you have any other questions, the perl script is pretty self- \nexplanatory and I'll be completely back online this weekend.  With  \nany luck I'll have some time in a hotel tomorrow (mmm, slow-as-dirt  \nhotel wireless, what fun) to work on parts (c) and (d).\n\nCheers,\nKyle Moffett\n\n\n\n#! /usr/bin/perl\n\nuse strict;\nuse warnings;\n\n## This table is for determining what order to show entries from different\n## source \"Maintainers\" files.  They are prioritized based on the number and\n## significance of each field, as listed in this table.  Any field not found\n## here will be assumed to have a significance of \"1\".\nmy %fieldprio = (\n\tp => 5,  ## Person\n\tm => 5,  ## Email\n\tl => 5,  ## Mailing List\n\tf => 0,  ## File\n);\n\n\nmy %mprio;\nmy %maint;\nmy $section;\nmy $origin;\nmy $pathprefix;\nmy $printorigin;\n\nwhile (<>) {\n\tunless (defined $origin and $origin eq $ARGV) {\n\t\tundef $section;\n\n\t\t## Get rid of extra slashes, unnecessary \"./\" entries\n\t\t$ARGV =~ s{//+}{/}g;\n\t\t$ARGV =~ s{(^|/)\\./}{$1};\n\n\t\t$origin = $ARGV;\n\t}\n\n\tchomp; s/\\s+/ /g; s/^ //; s/ $//;\n\t/\\S+/ or next;\n\n\tif (/^\\[ ?([^]]+) ?\\]$/) {\n\t\t$section = uc $1;\n\n\t\t$printorigin = 1 if $origin ne '-';\n\n\t\t$maint{$section}{$origin} ||= [];\n\t\t$mprio{$section}{$origin} ||= 0;\n\n\t\t## Figure out a useful path prefix if there is one\n\t\t$pathprefix = ($origin =~ m{(^.*/)(?!\\.\\.?$)[^/]+$})?$1:\"\";\n\n\t\tnext;\n\t}\n\n\tunless (/^([^:]+?) ?: ?(.*)$/) {\n\t\tprint STDERR \"$ARGV:$.: Invalid line: $_\\n\";\n\t\tnext;\n\t}\n\n\tmy($field,$value) = (lc($1), $2);\n\n\tunless (defined $section) {\n\t\tprint STDERR \"$ARGV:$.: Found field '\\u$field' before \",\n\t\t\t\t\"any subsystem declaration: $_\\n\";\n\t\tnext;\n\t}\n\n\t## Preprocess paths to make them absolute\n\t$value = $pathprefix.$value if $field eq 'f';\n\n\t## Update the sorting order\n\tif (exists $fieldprio{$field}) {\n\t\t$mprio{$section}{$origin} += $fieldprio{$field};\n\t} else {\n\t\t$mprio{$section}{$origin}++;\n\t}\n\n\tpush @{$maint{$section}{$origin}}, [$field, $value];\n}\n\nsub priosort ( $@ )\n{\n\tmy $section = shift;\n\treturn sort {$mprio{$section}{$b} <=> $mprio{$section}{$a}} @_;\n}\n\nfor $section (sort {$a cmp $b} keys %maint) {\n\tprint \"[$section]\\n\";\n\tfor my $origin (priosort $section, keys %{$maint{$section}}) {\n\t\tprint \"\\nOrigin: $origin\\n\" if $printorigin;\n\t\tprint \"\\u$_->[0]: $_->[1]\\n\" for @{$maint{$section}{$origin}};\n\t}\n\tprint \"\\n\\n\";\n}\n\n# vim:set ft=perl:\n"},{"id":"50888","messageId":"46C469A5.8020003@gmail.com","threadId":"9556","inReplyTo":"D31EF534-ACD1-426D-AF88-F152C23CB542@mac.com","subject":"Re: Storing Maintainers info around the kernel tree","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-16T15:13:41Z","receivedAt":"2007-08-16T15:13:41Z","isPatch":false,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/16/2007 03:04 PM, Kyle Moffett wrote:\n\n> On Aug 16, 2007, at 07:57:23, Rene Herman wrote:\n\n>> category as .gitignore, which would _be_ a property.\n>>\n>> If you do this stuff in files scattered around the tree, updating and \n>> moving stuff becomes a pain -- the tool would need to go edit files.\n> \n> From a practical standpoint we don't want to duplicate someone's \n> maintainer information in the attributes of every file they maintain.  \n\nIn a tree structure, you don't have to. As described earlier, the tool \n(git-prop) looks for the requested property being set first on the file \nitself, then on the directory in which it resides, then its parent, and so \non. If I read things right, this is also how properties work in subversion \nin fact.\n\nSo after\n\n$ git prop --set --name maintainer --value \\\n\t\"Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>\" drivers/ide/\nand\n\n$ git prop --set --name maintainer --value \\\n\t\"Alan Cox <alan@lxorguk.ukuu.org.uk>\" drivers/ide/ide-cd.*\n\nwe get:\n\n$ git prop --get --name maintainer drivers/ide/ide-cd.c\nAlan Cox <alan@lxorguk.ukuu.org.uk>\n\n$ git prop --get --name maintainer drivers/ide/ide-generic.c\nBartlomiej Zolnierkiewicz <bzolnier@gmail.com>\n\nNow, this override behaviour needs a tree structure ofcourse, but notice I \nset the \"maintainer\" property only to the name/address. The other \ninformation from the MAINTAINERS file would be using their own properties:\n\n$ git prop --set --name tree --value \\\n     \"quilt kernel.org/pub/linux/kernel/people/bart/pata-2.6/\" drivers/ide/\n\nand nothing under drivers/ide/ would override this value nor would it be \nrepeated anywhere. Alan takes care of more than ide-cd but only the actual \n\"maintainer\" value string would be set on the others as well and repeating \nthat much for different \"maintenance units\" is no different from the current \nMAINTAINERS file where it also is (well, would be, Alan is in fact only \nlisted for ide-cd it seems...) repeated in different entries.\n\n(as a slight difference -- in the above example, Alan's information _is_ \nrepeated over ide-cd.c and ide-cd.h where the current MAINTAINERS file just \nsays \"IDE/ATAPI CDROM DRIVER\", but that's a bit of an oddbal situation since \nyou normally have either single files or a tree that make up a \"maintenance \nunit\" -- and is in fact just a human versus tool difference).\n\n> It would be much easier to put in the \"kernel/somesubsys\" directory a \n> Maintainers file which has:\n\nIt's ofcourse possible, but note that if we want this stuff to be minimally \nmanual, moving files around (and deleting them) then requires editing these \nactual in-tree files via a tool.\n\nWith the properties deleting files just requires deleting any file-specific \nproperties alongside which is trivial since those are linked from the file.\n\nMoving stuff works by building a list of all properties that are set on the \nsource starting at the source and destination's highest shared parent \ndirectory and then reconstructing this list at the destination, striking \nproperties off the list that are already set at the destination.\n\nAdding properties, alongside added files or after the fact, could be done \nvia standard patch submissals via the kind of \"meta-diff\" that already \nexists for \"git move\".\n\nI really believe this stuff should be meta-data -- and these properties as \noutlined work well it seems.\n\n$ git prop --set --name git.ignore -V ./.gitignore .\n$ rm .gitignore\n\nThis is something I saw subversion also uses properties for. Takes the value \nfrom a file instead of the command line. .gitattributes are also easily \nincorporated into the property-system directly.\n\n$ git prop --set --name git.executable scripts/Lindent\n\nMust say I'm not particularly sure if this one has much value over the \ncurrent executable bit storage,but also from svn and example of a boolean \nproperty.\n\n$ git prop --set --name license --value \"GPL v2\" .\n$ git prop --set --name license --value \"GPL\" sound/alsa/\n\nand so on. The GPL v2 on the source root only works if you set the property \non everything that's not, so you may not want to but as a \"wouldn't it be \nnice if\" kinda thing. Makes for easy license analysis at least...\n\n$ git prop --set --name FIXME drivers/block/floppy.c\n\nOkay, that's probably overdoing it a bit, but as long as I'm having fun here...\n\nNote -- the properties would be versioned themselves ofcourse so that you'd \nalways have a tree where data and meta-data matched. Basically, I believe \nyou'd view the properties as just more data files, one per property, with \nthe exception that they'd not actually live in the working tree and are \nlinked from data (files/directories) that do.\n\nLong \"letters of intent\" this, but I'm by now in love with these things. \nMore comments (or implementations obviously :-) welcome. Any significant \nmisses in this?\n\nRene.\n"},{"id":"50889","messageId":"Pine.LNX.4.44L0.0708161128540.3757-100000@iolanthe.rowland.org","threadId":"9556","inReplyTo":"46C469A5.8020003@gmail.com","subject":"Re: [linux-pm] Re: Storing Maintainers info around the kernel tree","fromName":"Alan Stern","fromEmail":"stern@rowland.harvard.edu","sentAt":"2007-08-16T15:31:04Z","receivedAt":"2007-08-16T15:31:04Z","isPatch":false,"sender":{"key":"stern@rowland.harvard.edu","avatar":null},"body":"On Thu, 16 Aug 2007, Rene Herman wrote:\n\n> > It would be much easier to put in the \"kernel/somesubsys\" directory a \n> > Maintainers file which has:\n> \n> It's ofcourse possible, but note that if we want this stuff to be minimally \n> manual, moving files around (and deleting them) then requires editing these \n> actual in-tree files via a tool.\n> \n> With the properties deleting files just requires deleting any file-specific \n> properties alongside which is trivial since those are linked from the file.\n> \n> Moving stuff works by building a list of all properties that are set on the \n> source starting at the source and destination's highest shared parent \n> directory and then reconstructing this list at the destination, striking \n> properties off the list that are already set at the destination.\n> \n> Adding properties, alongside added files or after the fact, could be done \n> via standard patch submissals via the kind of \"meta-diff\" that already \n> exists for \"git move\".\n> \n> I really believe this stuff should be meta-data -- and these properties as \n> outlined work well it seems.\n\nPlease remember that not everybody uses git.  The MAINTAINERS data \nshould be available in the kernel source itself.\n\n(Maybe your suggestion is consistent with this -- I simply wanted to \nraise the point.)\n\nAlan Stern\n"},{"id":"50893","messageId":"46C47246.9020800@gmail.com","threadId":"9556","inReplyTo":"Pine.LNX.4.44L0.0708161128540.3757-100000@iolanthe.rowland.org","subject":"Re: [linux-pm] Re: Storing Maintainers info around the kernel tree","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-16T15:50:30Z","receivedAt":"2007-08-16T15:50:30Z","isPatch":false,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/16/2007 05:31 PM, Alan Stern wrote:\n\n> Please remember that not everybody uses git.  The MAINTAINERS data \n> should be available in the kernel source itself.\n\nIt may be useful to generate a MAINTAINERS file into releases yes.\n\nI must say though that \"why?\" would also be a question. I personally don't \nthink there's a whole lot wrong with more and more expecting people who \nsubmit patches (for whom this automation is intended) to be using git. Back \nin the BK days there were lots of reasons for resisting any and all \ndependency on the source code management tool but there don't seem to be too \nmany left today as far as I'm concerned.\n\nIf it's about non-developer users, I suspect it would to a fairly large \ndegree be an \"in theory\" thing to expect that said user does want the \ninformation in a downloaded releases, but not in git, and not online where \ngit-web could also easily display all the information right alongside the files.\n\nBut yes, sure, anything can be generated...\n\nRene.\n"},{"id":"50903","messageId":"46C4C40C.4050406@s5r6.in-berlin.de","threadId":"9556","inReplyTo":"46C47246.9020800@gmail.com","subject":"Re: [linux-pm] Re: Storing Maintainers info around the kernel tree","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2007-08-16T21:39:24Z","receivedAt":"2007-08-16T21:39:24Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Rene Herman wrote:\n> I personally don't think there's a whole lot wrong with more and more\n> expecting people who submit patches (for whom this automation is\n> intended) to be using git.\n\nYou mean \"people who frequently submit patches for various different\nsubsystems\".\n-- \nStefan Richter\n-=====-=-=== =--- =----\nhttp://arcgraph.de/sr/\n"},{"id":"50907","messageId":"46C4FD57.3000101@gmail.com","threadId":"9556","inReplyTo":"46C4C40C.4050406@s5r6.in-berlin.de","subject":"Re: [linux-pm] Re: Storing Maintainers info around the kernel tree","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-17T01:43:51Z","receivedAt":"2007-08-17T01:43:51Z","isPatch":false,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/16/2007 11:39 PM, Stefan Richter wrote:\n> Rene Herman wrote:\n\n>> I personally don't think there's a whole lot wrong with more and more\n>> expecting people who submit patches (for whom this automation is\n>> intended) to be using git.\n> \n> You mean \"people who frequently submit patches for various different\n> subsystems\".\n\nErm, I guess. Is that agreeing or disagreeing with me?\n\nRene.\n"},{"id":"50908","messageId":"Pine.LNX.4.44L0.0708162156550.9927-100000@netrider.rowland.org","threadId":"9556","inReplyTo":"46C4FD57.3000101@gmail.com","subject":"Re: [linux-pm] Re: Storing Maintainers info around the kernel tree","fromName":"Alan Stern","fromEmail":"stern@rowland.harvard.edu","sentAt":"2007-08-17T01:58:51Z","receivedAt":"2007-08-17T01:58:51Z","isPatch":false,"sender":{"key":"stern@rowland.harvard.edu","avatar":null},"body":"On Fri, 17 Aug 2007, Rene Herman wrote:\n\n> On 08/16/2007 11:39 PM, Stefan Richter wrote:\n> > Rene Herman wrote:\n> \n> >> I personally don't think there's a whole lot wrong with more and more\n> >> expecting people who submit patches (for whom this automation is\n> >> intended) to be using git.\n> > \n> > You mean \"people who frequently submit patches for various different\n> > subsystems\".\n> \n> Erm, I guess. Is that agreeing or disagreeing with me?\n\nDon't forget also that the MAINTAINERS information is (or should be!)\nused by people who want to submit bug reports, not just by people who\nsubmit patches.  Bug reporters shouldn't need to use Git.\n\nAlan Stern\n"},{"id":"50911","messageId":"46C5057C.5010602@gmail.com","threadId":"9556","inReplyTo":"Pine.LNX.4.44L0.0708162156550.9927-100000@netrider.rowland.org","subject":"Re: [linux-pm] Re: Storing Maintainers info around the kernel tree","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-17T02:18:36Z","receivedAt":"2007-08-17T02:18:36Z","isPatch":false,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/17/2007 03:58 AM, Alan Stern wrote:\n\n> On Fri, 17 Aug 2007, Rene Herman wrote:\n> \n>> On 08/16/2007 11:39 PM, Stefan Richter wrote:\n>>> Rene Herman wrote:\n\n>>>> I personally don't think there's a whole lot wrong with more and \n>>>> more expecting people who submit patches (for whom this automation \n>>>> is intended) to be using git.\n>>> \n>>> You mean \"people who frequently submit patches for various different\n>>> subsystems\".\n>> \n>> Erm, I guess. Is that agreeing or disagreeing with me?\n> \n> Don't forget also that the MAINTAINERS information is (or should be!)\n> used by people who want to submit bug reports, not just by people who\n> submit patches.  Bug reporters shouldn't need to use Git.\n\nLike I said:\n\n>> If it's about non-developer users, I suspect it would to a fairly large\n>> degree be an \"in theory\" thing to expect that said user does want the\n>> information in a downloaded releases, but not in git, and not online \n>> where git-web could also easily display all the information right \n>> alongside the files.\n\nAnd again, generating the MAINTAINERS file/info into releases is fine as well.\n\nRene.\n"},{"id":"50917","messageId":"46C53F50.9040107@s5r6.in-berlin.de","threadId":"9556","inReplyTo":"46C5057C.5010602@gmail.com","subject":"Re: Re: Storing Maintainers info around the kernel tree","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2007-08-17T06:25:20Z","receivedAt":"2007-08-17T06:25:20Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Rene Herman wrote:\n> On 08/17/2007 03:58 AM, Alan Stern wrote:\n> \n>> On Fri, 17 Aug 2007, Rene Herman wrote:\n>>\n>>> On 08/16/2007 11:39 PM, Stefan Richter wrote:\n>>>> Rene Herman wrote:\n> \n>>>>> I personally don't think there's a whole lot wrong with more and\n>>>>> more expecting people who submit patches (for whom this automation\n>>>>> is intended) to be using git.\n>>>>\n>>>> You mean \"people who frequently submit patches for various different\n>>>> subsystems\".\n>>>\n>>> Erm, I guess. Is that agreeing or disagreeing with me?\n>>\n>> Don't forget also that the MAINTAINERS information is (or should be!)\n>> used by people who want to submit bug reports, not just by people who\n>> submit patches.  Bug reporters shouldn't need to use Git.\n\nYes, problem reporters and people who infrequently (or for their first\ntime) submit patches, and even people who frequently submit patches but\nmost of the time only to the same one or two subsystems need an obvious,\ntool-independent way to get contact information.\n\n> Like I said:\n> \n>>> If it's about non-developer users, I suspect it would to a fairly large\n>>> degree be an \"in theory\" thing to expect that said user does want the\n>>> information in a downloaded releases, but not in git, and not online\n>>> where git-web could also easily display all the information right\n>>> alongside the files.\n> \n> And again, generating the MAINTAINERS file/info into releases is fine as\n> well.\n\nGood.  This generated data will be used by almost everyone except for a\ncertain special group of submitters.\n-- \nStefan Richter\n-=====-=-=== =--- =---=\nhttp://arcgraph.de/sr/\n"}]}