Re: [BUG] New Kernel Bugs

On Tue, Nov 13, 2007 at 09:08:32AM -0500, 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.
The latter is how we find out about bugs on uncommon hardware,
and the former is what we need to track them and overall quality.

A HUGE problem I have with current "efforts", is that once someone
reports a bug, the onus seems to be 99% on the *reporter* to find
the exact line of code or commit. Ghad what a repressive method.

99% on the reporter? Is that why I always try to understand the
reporters problem (*provided* it's in an area I know about) and come
up with a patch to test a theory or fix the issue?

I'm _less_ inclined to provide such a "service" for lazy maintainers
who've moved off into new and wonderfully exciting technologies, to
churn out more patches for me to merge (and eventually provide a free
to them bug fixing service for.)

That's "less" inclined, not "won't".

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
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/

Relevant Pages

  • Re: [BUG] New Kernel Bugs
    ... Today "many eyeballs" is simply not good enough and nature will route us around if we dont change. ... Contrast that flawed approach with how Linus does things.. ... and feeds back some trial balloon patches for the bug reporter to try. ...
    (Linux-Kernel)
  • Re: Reporting bugs and bisection
    ... Well less shit would happen if developers would take the time to at least test their patches before they were submitted. ... taking the attitude that 'if the reporter can't be bothered to do a bisection I can't be bothered to deal with the bug' is going way too far. ... it's very reasonable to ask the reporter if they can bisect the problem, but if they say that they can't, declaring that they are out of luck is not reasonable, it just means that it's going to take more thinking to find the problem instead of being able to let the mechanical bisect process narrow things down for you. ...
    (Linux-Kernel)
  • Re: Reporting bugs and bisection (was: Re: 2.6.25-rc8: FTP transfer errors)
    ... There is no perfect world where after reporting subtle bug it will be ... closely with the reporter working out why the reporter's failure was ... Bisect is just a tool. ... It is not something developers throw into user ...
    (Linux-Kernel)
  • Re: [BUG] New Kernel Bugs
    ... Today "many eyeballs" is simply not good enough and ... the onus seems to be 99% on the *reporter* to find ... I suspect the maintainers of the above drivers aren't aware that their ...
    (Linux-Kernel)
  • [PATCH 0/3] [RFC] Functional fix to zone_reclaim() and bring behaviour more in line with expectation
    ... I do not have the bug resolved yet although I believe patch 1 of this series ... addresses it and am waiting to hear back from the bug reporter. ... this patchset has not been tested heavily. ...
    (Linux-Kernel)