On Tuesday November 13, [EMAIL PROTECTED] wrote:
On Tuesday 13 November 2007 07:08, 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.
This is the only method that scales.
That sounds overly hash, and the rest of you mail sounds much more
moderate and sensible - I can only assume you were using hyperbole??
Putting the onus on the reporter is simply not going to work unless
you have a business relationship. In the community, we are all
volunteering our time (well, maybe my employer is volunteering my time
to do community support, but the effect is the same).
I would hope that the focus of developers is to empower bug reporters
to provide further information (and as has been said, git bisect is
a great empowerer). Some people will be incredibly help, especially
if you ask politely and say thankyou. Others won't for any of a
number of reasons - and maybe that means their bug won't get fixed.
To my eyes, the only method that scales is investing effort in
encouraging and training bug reporters. Some of that effort might not
produce results, but when others among those you have encouraged start
answering the newbee questions on the list and save you the time, you
get a distinct feeling that it was all worth while.
I think we are in agreement - I just wanted to take issue with that
one sentence :-) The rest is great.
NeilBrown
Developer has only 24 hours in each day, and sometimes he needs to eat,
sleep, and maybe even pay attention to e.g. his kids.
But bug reporters are much more numerous and they have more
hours in one day combined.
BUT - it means that developers should try to increase user base,
not scare users away.
And if the developer who broke the damn thing, or who at least
claims to be supporting that code, cannot reproduce the bug,
they drop it completely.
Developer should let reporter know that reporter needs to help
a bit here. Sometimes a bit of hand holding is needed, but it
pays off because you breed more qualified testers/bug reporters.
Contrast that flawed approach with how Linus does things..
he thinks through the symptoms, matches them to the code,
and figures out what the few possibilities might be,
and feeds back some trial balloon patches for the bug reporter to try.
MUCH better.
And remember, *I'm* an old-time Linux kernel developer.. just think about
the people reporting bugs who haven't been around here since 1992..
Yes. Developers should not grow more and more unhelpful
and arrogant towards their users just because inexperienced
users send incomplete/poorly written bug reports.
They need to provide help, not humiliate/ignore.
I think we agree here.
--
vda
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
