Messages in this thread | | | Date | Tue, 14 Sep 2010 19:46:46 +0200 | From | Florian Mickler <> | 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@xmission.com (Eric W. Biederman) wrote: > Florian Mickler <florian@mickler.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 >
| |