Messages in this thread | | | Date | Tue, 22 Apr 2008 09:06:44 +0200 | From | Ingo Molnar <> | Subject | Re: sched tree bisectability |
| |
* 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
| |