Cc: Mark Lord <liml@...>, Ingo Molnar <mingo@...>, <netdev@...>, <linux-pcmcia@...>, <linux-kernel@...>, <protasnb@...>, <linux-ide@...>, <bugme-daemon@...>, <linux-input@...>, Andrew Morton <akpm@...>, David Miller <davem@...>
..
Most of the regressions we have are easily identifiable and not of the type
where there could "50 other people" touching the relevant code. As a developer
(and former subsystem maintainer) I look hard at my own code when there's a
bug reported that could have come from recent updates there. Usually there are
not that many updates to consider, and tracking it down is just a matter of
being willing to do so.
Of late, I've given up on other developers fixing the stuff they break on my
own machines, and I generally just dive into totally unfamiliar code, and find
and fix it myself. Quite quickly, usually. And the bugs are often very apparent
just from looking at the source code diffs (patches) from recent history in
the code that's not working. This is not rocket science, and it doesn't require
a log2 download/rebuild/reboot process.
But yes, there are more difficult ones, like when my machine crashed yesterday
with some form of corruption showing up during JBD filesystem I/O. That's one
where the problem isn't going to be obvious to anyone, and I don't actually
expect anyone to go looking for it right away. If more such events happen,
then it will get more attention.
But things like broken drivers, in almost every case those are trivial
to track down and fix, even for people not familar with that specific code.
..
Nobody's blaming anyone here. I'm just asking that developers here do more
like our Top Penguin does, and actually look at problems and try to understand
them and suggest fixes to try. And not rely solely on the git-bisect crutch.
It's a good crutch, provided the reporter is a kernel developer, or has a lot
of time on their hands. But we debugged Linux here for a long time without it.
And I already volunteer my time here, thanks, BIG TIME, since 1992 or so.
Cheers
-
