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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 17 Jun 2012 12:40:55 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Jonathan Corbet <corbet@....net>
cc:	Greg KH <greg@...ah.com>,
	ksummit-2012-discuss@...ts.linux-foundation.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-2012-discuss] [ATTEND or not ATTEND] That's the
 question!

On Sat, 16 Jun 2012, Jonathan Corbet wrote:
> On Sat, 16 Jun 2012 12:50:05 +0200 (CEST)
> Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > A good start would be if you could convert your kernel statistics into
> > accounting the consolidation effects of contributions instead of
> > fostering the idiocy that corporates have started to measure themself
> > and the performance of their employees (I'm not kidding, it's the sad
> > reality) with line and commit count statistics.
> 
> I would dearly love to come up with a way to measure "real work" in
> some fashion; I've just not, yet, figured out how to do that.  I do
> fear that the simple numbers we're able to generate end up creating the
> wrong kinds of incentives.
> 
> Any thoughts on how to measure "consolidation effects"?  I toss out
> numbers on code removal sometimes, but that turns out to not be a whole
> lot more useful than anything else on its own.

I don't think there is an automated way.

How about not publishing the stats at all and just mention anything
related to them when something exceptional happens? E.g. out the the
blue 90% of the patches were submitted by hobbyists.

If you look at the stats of the last years, there is nothing really
interesting happening. We already know who employs the most kernel
developers and who of them is doing most of the work.

If companies really want to measure their "importance" or the
"performance" of their employees they can create their own stats and
abuse them for whatever they want.

Thanks,

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