[lkml]   [2007]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [BUG] New Kernel Bugs

    * Mark Lord <> 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-11-13 17:51    [W:0.023 / U:2.652 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site