[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17264.1187028697@turing-police.cc.vt.edu>
Date: Mon, 13 Aug 2007 14:11:37 -0400
From: Valdis.Kletnieks@...edu
To: Ray Lee <ray-lk@...rabbit.org>
Cc: Joe Perches <joe@...ches.com>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl
On Mon, 13 Aug 2007 10:09:08 PDT, Ray Lee said:
> On 8/12/07, Joe Perches <joe@...ches.com> wrote:
> > I grew weary of looking up the appropriate
> > maintainer email address(es) to CC: for a patch.
> >
> > I added flags to the MAINTAINERS file
> >
> > F: file pattern
> >
> > for each maintained block and a script to parse
> > the modified blocks for maintainer and list
> > email addresses.
>
> Why not parse git annotate or blame instead (other than it's freakin'
> slow)? Using the repository history has the added benefit of telling
> you a lot more fine-grained detail about who may want to know about
> your patch.
1) Not everybody wants to install git and pull down the whole kernel tree
just so they can do 'git blame' and point the report at the right cc:'s.
(Heck, *I* don't even have a 'git pull' of the kernel handy, and I probably
whinge about a lot more stuff than the average person reporting a bug)
2) A quick 'grep git' through Documentation/ doesn't find any actual mention
of how to find a web page that will do a 'git blame' for you.
I posit that if you want users to point bug reports at the correct cc:'s,
all the information needed has to be in the distributed linux-2.6.foo.tar file
(I'd allow that a functional "Go to this URL" suffices for this).
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists