linux-kernel - Re: [PATCH] get_maintainer.pl: append reason for cc to the name by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100913105434.62b150f7@schatten.dmk.lab>
Date:	Mon, 13 Sep 2010 10:54:34 +0200
From:	Florian Mickler <florian@...kler.org>
To:	Joe Perches <joe@...ches.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	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 Mon, 13 Sep 2010 00:57:45 -0700
Joe Perches <joe@...ches.com> wrote:

> On Mon, 2010-09-13 at 00:16 -0700, Eric W. Biederman wrote:
> > It is trivial for a human to look at a git log and see which changes
> > were just global cleanups and which changes were actual maintenance.
> > Apparently get_maintainers doesn't have that ability.
> 
> Do you have a useful, trivial or non-trivial algorithm
> to suggest or is that soft commenting?  All I'll say is
> AI can be a surprisingly difficult field.

:) indeed. 

> 
> > Have seen some files with something like 5 years of changes without a
> > single commit by a maintainer and the only changes happening to it are
> > global cleanup changes.
> 
> Then likely there's no actual maintainer for that file.

and which means that get_maintainer.pl --git will output either nothing
(if we somehow get its heuristics to filter correctly) or wrong people. 

> 
> > If get_maintainers would look at MAINTAINERS and validate or invalidate
> > that information by looking at git that would be useful.
> 
> Some entries in MAINTAINERS are outdated.
> Validating MAINTAINERS entries is probably best done once.
> 
> I suggest you try that concept out, see what you get, and
> make public the results.

It is easy to make get_maintainer.pl output less people. 
What is not easy is to get it to decrease false-positives while
not decreasing it's detection rate. 

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. 

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. 

Don't know. 

Regards,
Flo

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