Subject: Re: MPlayer broken under 2.6.15-rc7-rt1?
From: Arjan van de Ven <arjan@infradead.org>
To: Bradley Reed <bradreed1@gmail.com>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20060101115121.034e6bb7@galactus.example.org>
References: <20051231202933.4f48acab@galactus.example.org>
	 <1136106861.17830.6.camel@laptopd505.fenrus.org>
	 <20060101115121.034e6bb7@galactus.example.org>
Content-Type: text/plain
Date: Sun, 01 Jan 2006 12:26:12 +0100
Message-Id: <1136114772.17830.20.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2445
Lines: 50


> 
> DO YOU REALLY PREFER USERS NOT REPORT BUGS?

It is better to not have any reports than to have "bad" bugreports (bad
in the sense that they are caused by external kernel components), that
much is obvious, since such reports cost a lot of time from the
developers, time that could better be spent on "real" bugs. Often you
can deal with 3 real bugs in the time it takes to find out that a
bugreport is really a "bad" one (because you end up looking for things
that aren't there compared to things that are there and usually are
found quicker).

So the question is, are all tainted bugreports bad bugreports. The
answer again is simple, "no, not all". However, many are. So where to
draw the line?
A rather good line is "is it reproducable without the external
components"; if it is, then it's clearly a non-bad report (and the
non-tainted reproducer means the developer even has a chance to try it
during debugging). If it's not, there is a pretty high chance that it's
a "bad" report; this from my experience of being on the receiving end of
a distros bugreporting system for a long time. If the reported can't or
can't be bothered to reproduce it, the developer spending time on it is
generally a waste of time. 

What you have here is a bit of a gray area; you're using one of the
maybe-illegal binary modules that has a really long history of
introducing bugs that, just from the oops, may appear unrelated to this
module, and you can't reproduce it without. Just not because the bug
won't happen, but because you state that the application that triggers
it won't run without it. In this case, someone else apparently reported
the same issue but without external influences, so it looks like a real
bug. But we only know that because someone else saw it, not because of
your report... 

So getting back to your question:
I would say that I think it's generally better that bugs that cannot be
reproduced on an untainted kernel are not reported on lkml, but reported
to the vendor of the tainting module instead, simply because it's very
likely that it'll waste precious debug time. (debugging isn't the most
favorite task developers do, having it be a waste of time only makes it
more so)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/