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.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
