[kde-linux] Re: Loosing keyboard in KDE

[Duncan]

Duncan posted on Wed, 08 Jun 2011 17:40:18 +0000 as excerpted:

> FWIW, there has been discussion of another case where git bisect simply
> couldn't cut it, recently, on the kernel list.  Don't have time to find
> the link now, but it was in an H-Online kernel log article from about a
> week ago.  The problem there was a fixed and then reintroduced issue.

OK, here's the H-online kernel log article.  See the LKML discussion 
summary on pg2.  (FWIW I found all three discussions interesting.)

http://www.h-online.com/open/features/Kernel-Log-Hardware-and-3-0-
difficulties-1254308.html

And here's the direct-link to the git-bisect thread in question, "AAARGH 
bisection is hard", on gmane:
http://thread.gmane.org/gmane.linux.kernel/1139191

>From the looks of things git-bisect is about to get some new options/
features, to help both in chasing down such issues, and with a much 
faster (fewer iterations) "just tell me which subsystem it's in" mode.

What I think may ultimately happen is that there are three modes, the 
current one, the new subsystem one, and a third "hybrid mode" that would 
make a good new default, and that might take an iteration or two more, 
but will give give rather more feedback on where you are in the process.  

This hybrid mode would start with the subsystem mode, nail it down, then 
continue within the single subsystem.  Because it would work in two 
stages and the split-points for the first wouldn't necessarily be the 
most efficient split-points to go all the way, it might take a couple 
more iterations.  However, it would give much more feedback, and a reward 
and good stopping point much quicker, half-way thru or so, for those who 
would otherwise give up before they got done.

Until it found the subsystem, it would tell how many more rounds until 
the subsystem was found as well as estimate the total to go as it does 
now, tho the total would be much less accurate at that point, since it'd 
be going by subsystem first.  What would happen is that it would count 
the commits per remaining subssystem and would assume the worst-case 
subsystem would be chosen.  As it began zeroing in on a specific 
subsystem, however, every time it eliminated the worst-case subsystem 
from the remaining candidates, the total rounds estimate would drop by 
more than one.  This would make the progress seem faster to the user in 
much the same way as the "remaining time" estimate on a download will 
often drop quite fast (say 5 seconds go by but you find it has shaved a 
minute off the estimate) as the connection picks up speed.

When it found the subsystem and/or merge-commit in question, it would 
announce the subsystem/merge-commit and its author/committer, and that 
information would then be included in the summary after each round, thus 
giving the user an early reward as the initial goal was reached.

This would make the process far more interesting and rewarding especially 
for users that don't actually read code and that aren't closely enough 
involved with the project in question to otherwise find the process 
reasonably interesting, instead of the long dry slogging session of we 
have now.

Additionally, bisect would work far more intuitively as it wouldn't be 
wandering into commits that appear to be before the last known good 
version (this can happen said commits were on a branch that wasn't yet 
merged), at least until the merge-commit is nailed, at which point it 
could explain why it might appear to be testing too early commits, 
because it had to nail down the commit within the merge that caused the 
problem.

This would make the git-bisect far more user-friendly and thus far more 
likely for users to complete their bisects, as they'd be getting much 
more rewarding intermediate feedback along the way.

Plus, just narrowing it to a specific merge commit is a huge step toward 
solving the problem, as at that point the subsystem maintainer that's 
familiar with the code and may well be able to spot the problem, can get 
involved.  So for bisects that can't be finished for whatever reason, as 
was the above case, or which the user simply gives up on before they get 
it all the way done, the result is still useful.

So I'm really looking forward to these changes.  And since it's Linus 
suggesting them, they're extremely likely to happen, since he originally 
designed git and knows what he's talking about, and everyone involved 
knows that.  It's not just some yahoo saying it should have such 
functionality, it's Linus.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman