Re: sched tree bisectability

[Ingo Molnar <mingo@elte.hu>]

* David Miller <davem@davemloft.net> wrote:

> While trying to bisect a regression added by the sched tree merges 
> today, I found the following gem that broke compilation mid-bisect:
[...]

> rt_bandwidth does not have a rt_runtime_lock member, so the compile 
> fails.  The very next changeset adds it:

sorry, i broke that bisection point and i should have noticed this and 
should have backmerged that chunk.

i've just added some scripting to avoid this in the future - the 
scheduler tree gets built on every commit point before it's pushed out. 
I just ran it through the outstanding scheduler patches (there's a 
hundred more pending) and they all pass this test.

I'm wondering whether there are any other maintenance practices others 
use to keep things like this slip through.

It could be caught on the testing side via a new git-checkout feature:

   git-checkout --random base..head

which would pick a random commit from a git tree (from the range of 
commits given), which could be combined with make randconfig? This could 
be used in pre-push testing.

Another thing we might think about is when neither care from the 
maintainer nor any testing caught an unusable commit - then we could 
perhaps, as a last-ditch effort teach git-bisect to avoid known "100% 
unusable" commit points.

Something like a (append-only, constantly growing, but not too huge) 
repository of known-unusable commits via a special exceptions file like 
.gitignore - say .git/git-bisect-unusable. [Plus perhaps a git-bisect 
--ignore-bad option so that if someone wants to run a pristine bisection 
it can be done too.]

The semantics would be to pass along this information across a pull as 
well, so that the known-unusable commit points would.

The downside of such an approach would be that the file would grow 
indefinitely, and would never shrink. That does not feel too good.

	Ingo