Re: git-rev-list: "--bisect" flag

From: Ingo Molnar <mingo@elte.hu>
Date: Jun 19, 2005, 17:36 UTC
Message-ID: <20050619173634.GA25768@elte.hu>
In-Reply-To: <Pine.LNX.4.58.0506190951330.2268@ppc970.osdl.org>

* Linus Torvalds <torvalds@osdl.org> wrote:

Show 6 quoted lines

> NOTE NOTE NOTE! The above is all based on random distribution of bugs, 
> where all commits count equally, which is obviously not even true. You 
> coudl try to do a "weighted bisection", where you weigh commits 
> differently: you might say, for example, that if the author field 
> matches the string "torvalds", then the likelihood of a bug is 
> obviously miniscule, so such a commit only counts as 0.1.

another assumption is that the number of testsystems is a power of two minus 1. With 2 or more testsystems (and automated testing) you could dissect the search space into 3, 5 or more roughly equal pieces in the first step (2, 4, 8 ... sections are already supported via the bisect flag). To decrease the time needed to find a bug it makes sense to increase the number of testsystems, especially if it takes minutes to boot - or if it takes minutes (or hours) to reproduce a bug. If each box runs a separate kernel then statistically, if one of them triggers the bug, only half of them have to be rebooted with new kernels, the others would still be kept running in a "commit space of interest".

But i guess it's not a big degradation to just round the test method to the nearest power-of-2 bisection method.

	Ingo