Incremental bibisect (Re: minutes of ESC call ...)

On Thursday 05 of April 2012, Michael Meeks wrote:
> * new bytemark tinderboxen (Norbert)
...
>       + Other ideas (Caolan)
...
>               + or magically do bibisect packing ?
>               + few 100'Gb's of storage ...

 Actually, this was one of the things I have in my todo to bring up whenever I 
get to it, so that whenever may be as well now.

 As far as I understand it, currently bibisect is generated manually as one 
big blob from scratch whenever Bjoern gets to it. Also, as far as I 
understand it, developers mostly do not use git bisect, because it takes a 
lot of time (for those not lucky enough to have <= ~1/4hour rebuild time, an 
awful lot of time). So, in case nobody has yet come up with this yet, I'd 
like to bring up the idea of combining these two and make bibisect useful 
even for normal development.

 I've already asked a bit who uses git bisect, and mostly I've been told that 
people have tried it, but it just takes too much time. No wonder, even if one 
e.g. notices a master regression since the last week, that's still a number 
of git bisect steps, and they can take long, especially if this Luboš has 
meanwhile changed rtl/ustring.hxx again.

 So I think it would make sense if we had a special bibisect repository for 
master and the stable branch that would be continually updated at reasonable 
intervals. I've been told that we should have enough of storage capacity 
somewhere, and I was originally going to offer my build machine for this if 
needed (it's got nothing to do during the nights anyway, and more than one 
rebuild and repack daily probably shouldn't be needed). I have no idea about 
the storage requirements of this or the time needed for reasonable repacking, 
but if there was a better machine to do this, the better.

-- 
 Lubos Lunak
 l.lunak@suse.cz