Re: [BUG] New Kernel Bugs

[Ingo Molnar]

* Mark Lord <liml@xxxxxx> wrote:

> Ingo Molnar wrote:
> ..
>> This is all QA-101 that _cannot be argued against on a rational basis_, 
>> it's just that these sorts of things have been largely ignored for years, 
>> in favor of the all-too-easy "open source means many eyeballs and that is 
>> our QA" answer, which is a _good_ answer but by far not the most 
>> intelligent answer! Today "many eyeballs" is simply not good enough and 
>> nature (and other OS projects) will route us around if we dont change.
> ..
>
> QA-101 and "many eyeballs" are not at all in opposition.

yes, absolutely so - that's why i used the "good" qualifier. "Good is 
not good enough" calls for additional efforts to make it more efficient, 
not for the abolition of the many eyeballs concept (which would be 
absurd). So what i wanted to say is that _sole_ reliance on the large 
numbers of eyeballs is a fundamental mistake. It's even sometimes used 
as an excuse to merge questionable stuff. "we'll find any bugs, many 
eyeballs will make bugs shallow". In reality the many eyeballs are not 
infinite, nor should they be taken for granted if they are used for 
bogus things. We have to make sure the eyeballs stay 'many', and we also 
have to make sure they are not wasted. It's a physical resource that 
must be intelligently handled. Its positive effects can be easily wasted 
and we do that today.

for example git-bisect was godsent. I remember that years ago bisection 
of a bug was a very laborous task so that it was only used as a final, 
last-ditch approach for really nasty bugs. Today we can autonomouly 
bisect build bugs via a simple shell command around "git-bisect run", 
without any human interaction! This freed up testing resources 
enormously and made bisection one of the _first_ things that are tried 
when bugs are met. We just need more of this (distros should offer 
pre-built kernel rpm 'farms' for every important commit point and 
automated tools for users to easily specify breakage points, without 
them having to install those kernels individually) , and everyone should 
be aware of the fact that we still suck (we merge too much crap and 
still dont have good enough tools to de-crappify what we merge) and that 
we are losing testers.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/