Date:	Tue, 14 Sep 2010 19:46:46 +0200
From:	Florian Mickler <florian@...kler.org>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	Joe Perches <joe@...ches.com>,
	Christoph Hellwig <hch@...radead.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Wolfram Sang <w.sang@...gutronix.de>
Subject: Re: [PATCH] get_maintainer.pl: append reason for cc to the name by
 default

On Tue, 14 Sep 2010 10:19:33 -0700
ebiederm@...ssion.com (Eric W. Biederman) wrote:
> Florian Mickler <florian@...kler.org> writes:
>



> What is needed is something other than output that is a list of
> email addresses.
> 
> email address foo had x% of non-author signed off bys
> email address foo had y% of author signed off bys
> email address foo had y% of author commits.
> email address foo came from the Maintainers file.

Currently get_maintainer.pl only does signed-off-by counting, it doesn't
take authorship in account, IIRC. That is a good point. It's
information that is easily available. 

> 
> Additionally for email addresses that hit less often a list
> of patch subject titles, and truncated sha1 patch ids.  So
> with luck you can tell at a glance the person is of interest
> and if not you can look at their commits quickly and see.

An interactive mode in git shortlog form of the last year should be
possible, i guess. 

I wonder, if git send-email --cc-cmd allows for directing input towards
get_maintainer.pl. That would be awesome.

> 
> That is all pretty trivial, it should be fast and it should with
> a little care let the bogus results be filtered out quickly.
> 
> > As far as I can see, Andrew is in favor of not caring about
> > false-positives in order to not sacrifice the detection rate of the
> > tool. 
> 
> Which means in time every long time developer will be copied on every
> patch.  That is what we have lkml for.  I don't have a problem with the
> tool returning false positives.  I do have a problem with the tool
> taking away the ability and the responsibility of developers to pay
> attention to which human beings they are sending their patches to.

Fair enough. It does a one year cut-off for the history. But maybe that
is not the best approach. 

> 
> I don't want the tool to do the filtering.  I want the tool to give
> enough information that the person using the tool can get a feel for the
> development history of the affected files and suggestions with a couple
> of metrics how useful someone is when Cc'd on a commit.

I think this is a good approach. 

> 
> > My approach tried to lower the impact of false positives by allowing
> > people to filter between "cc'd as maintainer" and "cc'd as
> > commit_signer".  The former is pretty much never a false positive (as
> > long as MAINTAINERS is up to date) while the latter is more of a
> > hit'n'miss kind of method. 
> 
> And right now get_maintainer.pl is decreasing the relevancy of cc lines
> in commits, which if get_maintainers.pl is used enough could be a
> vicious circle.
> 
> The problem as I see it is you present of a list of email addresses
> without enough information for someone using the tool to guess how
> accurate the results are.

Yes. I guess my patch adresses that somewhat, as it puts more
information in the output by default. But it only uses the information
already present in the script. 

Regards,
Flo

> 
> Eric
> 
--
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