Hemmann, Volker Armin wrote:
> On Donnerstag, 20. Dezember 2007, you wrote:
>> The subject line is wrong.
>> You apparently run Linux, but not Linux 2.6.23.y.
>
> first of all, apart from this oops all other oopses I reported were with a
> not-tainted kernel. You might want to read the other mails I have sent.
>
> Also, besides of the reiser4 patch there is no other patch added to the
> kernel. And since people have had successfully reported problems with
> heavily distro-patched kernels in the past it looks a little bit hypocritical
> to put my reports aside because of one single patch - don't you think?
I didn't say anything about putting your report aside.
For successful reports (as in 'leading to a fix'), it's among else
necessary that the issue can be narrowed down enough. Sometimes this is
a quick process; e.g. user X finds a very specific driver bug while
using a patched and old kernel, driver developer Y takes the time to
confirm this bug in a recent mainline kernel because he already had a
good idea where to look and how to recreate the respective conditions,
and fixes the bug. Sometimes it takes much much more work to identify
the circumstances of the bug. It is then necessary that the reporter
knows exactly what he is running, simplifies his system to eliminate as
many potential causes for problems as possible, and always clearly
states under what circumstances the bug happens.
If you already found the bug in an untainted (but patched?) kernel, then
what information does another report against a tainted kernel add? The
tainted kernel has more unknowns than the untainted one. Progress can
only be made if the number of unknowns are successively reduced.
Regarding other people's reports and hypocrisy and whatnot: I myself am
monitoring a few distro bug trackers more or less frequently for bug
reports concerning the kernel subsystem I'm interested in. With varying
success though. In order make use of a report against a distro kernel,
I need to have a good picture of what stuff is in that kernel. Looking
at distro bug trackers does only work for me because my field of
interest is a driver subsystem which is somewhat decoupled from other
kernel parts; so if there is trouble concerning hardware covered by this
subsystem, it is usually not too hard to figure out whether the problem
is in this subsystem or somewhere else. If it weren't that easy most of
the time, I might for example depend on the reporters to test specific
mainline kernels or specific development kernels. (Though the latter
becomes necessary after all in cases when more targeted debug output is
needed from the reporter, or in order to test proposed fixes without
having to wait for the distributor to build a test package for the
reporter.)
--
Stefan Richter
-=====-=-=== ==-- =-=--
http://arcgraph.de/sr/
--
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
