..
No, that's a one-way street, where the developers insist that the bug discover
do 100% of the work of finding/fixing the bug.
A two-way street is when we help each other, where the developers
might point out some likely commits, and the bug discover takes
additional time to patch/retest around them.
Years ago, Linus suggested that he opposed an in-kernel debugger
mainly because he preferred that we *think* more about the problems,
rather than just finding/fixing symptoms.
This 100% reliance upon git-bisect is worse than that.
It has people now just tossing regressions into the code left and right,
knowing that they can toss all of the testing back at the poor folks
whose systems end up not working.
..
I just happen to find/report a lot of regressions.
And every single damn one so far has taken days of my
time to track down, and in most cases fix by myself.
All of them up until this one, have not been bisectable.
Yes, this one does seem to reproduce reliably now,
so it could be bisected if I wanted to take another day
out of my life for it.
I did bisect one other issue back in 2.6.24 (or .23?),
and that took about 9 hours in total.
I'd really like a hand or two with some of these bugs
at some point from the folks who keep breaking things.
Cheers
--
