Message-ID: <46C522F5.9080802@gmail.com>
Date:	Fri, 17 Aug 2007 06:24:21 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Junio C Hamano <gitster@...ox.com>
CC:	Kyle Moffett <mrmacman_g4@....com>,
	Satyam Sharma <satyam@...radead.org>,
	Al Viro <viro@....linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>, git@...r.kernel.org,
	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>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

On 08/16/2007 09:00 PM, Junio C Hamano wrote:

> Git or no git, I think a file that can be viewed with less,
> edited with regular editor and processed with sed/perl/grep
> tools is the way to go.  I do not think adding 600+ patches to
> the single MAINTAINERS list is workable in the longer term, as
> it would become the single file many subsystem people need to
> update and is asking for merge conflicts, but I think a file
> with known name (say, "CcMe.txt") sprinkled in relevant
> subdirectories, perhaps with the same format originally
> suggested for MAINTAINERS, would make a lot more sense.
> 
> That would give people who work with tarballs and patches, or a
> subsystem managed with something other than git (one of the most
> important one is quilt), the equal access to the necessary data.

That is ofcourse an argument but I believe a bit of a non-argument at the 
same time in practice.

There's really not much point in pretending that non-git users are still 
first class citizens anyway; Linus' own suggestion of using git-blame would 
tie things to git as well, as do for example frequent requests to bisect a 
problem. I moreover feel there's absolutely nothing wrong with that, given 
that there's nothing wrong with git.

It's the kernel's source code management tool, is included out of the box in 
most distributions nowadays and is GPLd meaning that the tool (itself) won't 
keep anyone from exporting data from it and importing it into something else 
if someone cares to. Also, I never managed to stay un-annoyed at source code 
management tools long enough to understand why I wanted to use them but have 
been using git for months now so as far as I am concerned, it appears to 
even be a good tool.

But, well, anyways, I did look at a git repo a bit but will unfortunately 
not be able to follow up the proposal with actual (good) code in a sensible 
timeframe, let alone "quickly", which means I was hoping others would agree. 
I believe these properties make for an elegant setup with many possible uses 
including the maintainers information, but if you disagree I guess I'm going 
to shelve it...

> Even with git, it is my understanding that kernel community
> works largely on patches exchanged over e-mails, between people
> who do use git and people who do not.  You would want to have
> something you can easily transfer over e-mail in the patch
> form.
> 
> We _could_ invent a new "patches to properties" git diff output
> format that "git apply" can understand to propagate that
> information

Yes, not unlike the current git move "meta-diffs" ...

> but that approach is making it less interoperable with others, and you 
> need to demonstrate the benefit far outweighs that.  I do not see it for 
> this particular application.
> 
> There may be places for "properties" that would be useful to git, but I 
> do not think the "find whom to send patches to" is one of them.

The important reason for wiring this into git directly would be keeping the 
meta-data in sync with the data it refers to in an automated fashion. With 
manual intervention, there's much more opportunity for things to grow stale.

In practice, it may not be a huge problem. It certainly is with the current 
MAINTAINERS file but if one does finer-grained data around the tree, that 
will probably help.

It's also not a now or never thing fortunately. If git does ever grow these 
properties, the issue can be revisited, perhaps at that time both with the 
experience of what the finer-grained in-tree solution did not solve and even 
fewer people around that care about not making git even more of an intrinsic 
part of development.

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