* 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-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
