linux-kernel - Re: [Ksummit-2012-discuss] [ATTEND or not ATTEND] That's the question!

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: <4FF6B6E8.7080306@parallels.com>
Date:	Fri, 6 Jul 2012 13:59:04 +0400
From:	Glauber Costa <glommer@...allels.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
CC:	"J. Bruce Fields" <bfields@...ldses.org>,
	Jonathan Corbet <corbet@....net>,
	<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!

>>
>> Resurrecting this one.
>>
>> So something just came across my mind: When I first read this thread, my
>> inner reaction was: "People will find ways to bypass and ill-optimize
>> their workflow for whatever measure we come up with".
>>
>> That's is pure human nature. Whenever we set up a metric, that becomes a
>> goal and a bunch of people - not all - will deviate from their expected
>> workflow to maximize that number. This happens with paper count in the
>> scientific community, for the Higgs Boson's sake! Why wouldn't it happen
>> with *any* metric we set for ourselves?
>>
>> So per-se, the fact that we have a lot of people trying to find out what
>> our metrics are, and look good in the face of it, is just a testament to
>> the success of Linux - but we know that already.
>>
>> The summary here, is that I don't think patch count *per se* is a bad
>> metric. Maybe we should just tweak the way we measure a bit to steer
>> people towards doing more useful work, and that would aid our review.
>>
>> The same way we have checkpatch, we can have something automated that
>> will attempt to rule out some trivial patches in the counting process.
>> We can scan a patch, and easily determine if each part of it is:
>>
>> * pure whitespace
>> * pure Documentation change
>> * comment fix
>>
>> And if a patch is 100 % comprised by those, we simply don't count it.
>> People that just want to increase their numbers - they will always
>> exist, will tend to stop doing that. Simply because doing it will not
>> help them at all.
> 
> OTOH, documentation changes or comment fixes, and even sometimes pure whitespace
> fixes, can be very valuable contributions. This can be a useful and ungrateful
> work and that deserve credit.
> 
> We just can't find an automated and right way to evaluate a contribution.
> 

I am not saying or implying that they are not. I am merely pointing out
that metrics are good and healthy for us, but all of them will have
their perks, and a group of people will optimize for that.

I doubt that we'll stop having Documentation patches, for instances, if
we stop counting them. People who understand the value of it, will still
do it. They will just stop doing it for the sake of doing it, and even
worse, divided in a thousand patches what could easily be sent in just one.

Furthermore, I believe to be undeniable that even though those
contributions are indeed, valuable, they are not by any means as
valuable as the "real work", as Thomas describes.
--
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/