On Wed, Sep 8, 2010 at 8:00 PM, Stephan Assmus <superstippi@xxxxxx> wrote: > So the problem exists somewhere between revision r37184 and r38581. The >> screen starts with "normal" white and gets brighter and brighter. The hard >> disk is working all the time so it looks like Haiku is booting. >> > > > So there are like 1400 revision inbetween. I am too lazy to compute how > many revisions you'd have to test using binary searching, but you don't have > to test all 1400. Hint, hint. ;-) > > Disclaimer: I'm very math challenged. ;) But if I'm correct, it would take something like testing 10 nightlies at most to narrow it down. Just pick a revision in the middle if those two end points (something like r37884. I'm making these numbers up, but you get the idea.). Is the problem still there? If it is, then that means it was introduced earlier. Pick a revision half way between that one at r37184 (around r37534 for instance) and try again. If it isn't, then that means it was introduced later. Pick one around r38234 (halfway between r37884 and r38581) and try again. Each time you cut the field in half and see if the problem is there or not. After maybe 10 iterations of this at most, you should have it narrowed down to the revision that introduced the problem, or at least the relevant nightly build. At that point you or the developers could look through the commits between those 2 revisions and see which ones could cause the problem you're seeing. (This probably won't look quite right if you're not using a fixed width font to display it.) 0 working revision area ? unknown possibly broken revision area # broken revisions works...........................broken ???????????????????????????????? you choose the middle, and since it works, you know it broke later, so you choose the halfway point on the later side. 0000000000000000???????????????? this time it's working again still... so again we choose the halfway point later on. ----------------00000000???????? This time it's broken, so we know it happened earlier, so we choose a halfway earlier revision. ------------------------????#### broken again... so we scoot earlier ------------------------??##---- this one works, so we know it happened this revision and the broken revision we tested in the last iteration. ------------------------0?------ This way it only takes a small number of tests to narrow it down from a large number of nightly builds to just the two between which it broke. (Remember, you don't have to narrow it down from 1,400 to begin with, just the nightly build revisions. One you know which nightly it broke on, that's enough to narrow it down to the relevant prior day's worth of commits to look at for the guilty culprit.) Hopefully I explained it well enough. :)