Re: sched tree bisectability

From: Ingo Molnar
Date: Tue Apr 22 2008 - 03:07:56 EST



* David Miller <davem@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/