linux-kernel - Re: 463 kernel developers missing!

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]

Date:	Mon, 28 Jul 2008 16:46:24 -0400
From:	Dave Jones <davej@...hat.com>
To:	Theodore Tso <tytso@....edu>, Jon Smirl <jonsmirl@...il.com>,
	Simon Arlott <simon@...e.lp0.eu>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: 463 kernel developers missing!

On Mon, Jul 28, 2008 at 04:22:36PM -0400, Theodore Tso wrote:
 > On Mon, Jul 28, 2008 at 03:00:13PM -0400, Jon Smirl wrote:
 > > Other people aren't perfect, I've found over 1,000 typos in the those
 > > names and emails. We need a validation mechanism.
 > > 
 > 
 > You keep using the word "need"; I do not think it means what you think
 > it does.  :-)
 > 
 > Seriously, why is it so important?  It's a nice to have, and I
 > recognize that you've spent a bunch of time on it.  But if the goal is
 > to get better statistics, and in exchange we forcibly map all Mark
 > Browns to one e-mail address, and/or force them to all adopt middle
 > initials (what if there are two Dan Smith's that don't have middle
 > initials) just for the convenience of your statistics gathering, I
 > would gently suggest to you that you've forgotten which is the tail,
 > and which is the dog.

I'm beginning to question just how useful the continued measuring
of things like Signed-off-by's is.   Last week at OLS, I overheard
a conversation where someone was talking about the "top 10" lists
that Greg has been talking about at various conferences.
The conversation went along the lines of "my manager really wants
to see us on that list, at any cost".
Whilst the niave may think 'more patches == more better', this isn't
necessarily the case given we have nowhere near enough review bandwidth
*now*, and flooding with a zillion trivial patches really isn't going
to make that job any easier.

Getting patches into the tree is easy, we've proven that.
As things stand now, it's also fairly easy to 'game' the system
by committing something in 10 changesets when it could be done
just as easily in 2-3.

How about we start measuring things that actually matter, like..

"How many patches were reviewed before they went in"
"How many patches were directly responsible for a bug"
"How many patches actually fixed something anyone cares about"
"How many patches are responsible for just 'churn'"

	Dave

-- 
http://www.codemonkey.org.uk
--
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/