Incremental bibisect (Re: minutes of ESC call ...)
l.lunak at suse.cz
Thu Apr 5 08:49:37 PDT 2012
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.
l.lunak at suse.cz
More information about the LibreOffice