Date:	Wed, 15 Aug 2007 03:19:09 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Al Viro <viro@....linux.org.uk>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>, git@...r.kernel.org,
	Junio C Hamano <gitster@...ox.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Mariusz Kozlowski <m.kozlowski@...land.pl>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

On 08/14/2007 09:33 PM, Al Viro wrote:

> FWIW, I suspect that we are looking at that from the wrong POV.  If
> that's about "who ought to be Cc'd on the issues dealing with <list
> of pathnames>", why does it have to be tied to "who is maintainer for
> <pathname>"?
> 
> I'm not suggesting something like fs.ext2@...nel.org with something
> like majordomo allowing to add yourself to those, but something less
> extreme in that direction might be worth thinking about...  Hell,
> even simple
> $ finger fs/minix/dir.c@...kernel.org
> with majordomo-like interface for adding yourself to such lists
> might solve most of those problems...

It mostly is just about that it seems. However, this would not also allow 
the other information currently in the MAINTAINERS file to be queried in 
similar ways.

Git could grow a generic file meta data implementation through the use of 
tags, sort of like tags on multimedia files although while with multimedia 
files the tags are in fact stored as a file header, here you'd keep them 
just in git. Any project using git would be free to define its own set of 
info tags and you'd supply them to git simply as a list of

<tag>=<value>

pairs:

$ git info --add drivers/ide/ide-cd.c <<EOF
CC="Alan Cox <alan@...rguk.ukuu.org.uk>", linux-ide@...r.kernel.org
EOF

Or as a more expansive example, with the tags set on a directory (and the 
output shown this time):

$ git info drivers/infiniband/
CC="Roland Dreier <rolandd@...co.com>"
CC="Sean Hefty <mshefty@...ips.intel.com>"
CC="Hal Rosenstock <halr@...taire.com>"
CC=openib-general@...nib.org
W=http://www.openib.org/
T=git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

$ git info --type="W" drivers/infiniband/
http://www.openib.org/

The project can link the actual tags such as CC, W and T to --options for 
the "info" command in the git configuration file for the tree (and/or just 
define a few upfront I guess) making it look nicer:

$ git info --cc drivers/infiniband/
"Roland Dreier <rolandd@...co.com>"
"Sean Hefty <mshefty@...ips.intel.com>"
"Hal Rosenstock <halr@...taire.com>"
openib-general@...nib.org

$ git info --website drivers/infiniband/
http://www.openib.org/

$ git info --tree drivers/infiniband/
git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

Extra: when you have such an implementation, you can use it for other 
purposes as well such as the summary Documentation/ files want for the 
00-INDEX files:

$ git info --summary Documentation/BUG-HUNTING
brute force method of doing binary search of patches to find bug.

And importantly -- when queuried for a file that itself doesn't have the 
requested info tag:

$ git info --cc drivers/infiniband/core/addr.c

git looks for the tag on the drivers/infiniband/core/ directory next, and 
then on drivers/infiniband/, where it finds it. linux-kernel@...r.kernel.org 
would be the final fallback, being set on the project root.

I'd really like something like this. As long as projects are both free to 
use and not use them and free to define their own set of tags I believe this 
would work very nicely.

Once you have these tags, you can basically use them for anything.

Rene.

-
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