Thread (146 messages) 146 messages, 44 authors, 2007-11-19

Re: [BUG] New Kernel Bugs

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2007-11-13 21:58:26
Also in: alsa-devel, linux-ide, linux-input, lkml

On Tue, 13 Nov 2007 22:33:58 +0100 Jörn Engel [off-list ref] wrote:
On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote:
quoted
I just find it weird that something can be known broken for several -rc*
kernels before I happen to install it, discover it's broken on my own 
machine,
and then I track it down, fix it, and submit the patch, generally all 
within a
couple of hours.  Where the heck was the dude(ess) that broke it ??  AWOL.

And when I receive hostility from the "maintainers" of said code for fixing
their bugs, well.. that really motivates me to continue reporting new ones..
Given a decent bug report, I agree that having the bug not looked at is
shameful.  But what can a developer do if a bug report effectively reads
"there is some bug somewhere in recent kernels"?  How can I know that in
this particular case it is my bug that I introduced?  It could just as
easily be 50 other people and none of them are eager to debug it unless
they suspect it to be their bug.
It's relatively common that a regression in subsystem A will manifest as a
failure in subsystem B, and the report initially lands on the desk of the
subsystem B developers.

But that's OK.  The subsystem B people are the ones with the expertise to
be able to work out where the bug resides and to help the subsystem A
people understand what went wrong.

Alas, sometimes the B people will just roll eyes and do nothing because
they know the problem wasn't in their code.  Sometimes.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help