Hi all, bibisect stands for "binary bisect" and is intended to help QA for LibreOffice 3.5. Regressions are a most annoying artifact that unfortunately come with software development and QA. However, regressions are a misfeature we want to deal with quick and early as they might get harder and harder to triage and fix as time passes.
Because the way git stores its stuff, this download: http://people.canonical.com/~bjoern/bibisect-3.5.lzma contains: - 53 complete office installs between the creation of the core repo and the -3-5 branchoff (thats >5000 commits) - at 450MB each, that would be ~22GB total - however, it is only 749MB total download size, thats <15MB per installation And one does not need to install them in parallel as one can switch through all of them with a quick "git checkout source-hash-XXXXXX" -- one switch costs <1 second). As developers are helped extraordinary by knowing as exact as possible when some regression first showed up in the product there is some value in making this task as easy and fast as possible. In source code there is the possibility to bisect: http://book.git-scm.com/5_finding_issues_-_git_bisect.html and with the core repository, we have -- in theory -- the ability to exactly identify where the regression was introduced. In theory, because you need a compile and install to triage the bug and different from most other projects, this still takes quite some time for LibreOffice and thus we cannot fix regressions as quick as we should. This is were bibisect comes in: It contains fully completed LibreOffice installations between two major releases(1) and you can bisect your regression (to identify when the offending change happened). Once the range where the bug was introduced is identified, developers will be much more eager to fix the issue (as the scope can not only be guessed better, it is also known to be quite limited now). Bibisect also has the binary installs tagged with the commit-id from the source repository -- which is the only thing identifying a build that really helps developers. And by the order they are on the branch one can quickly see which build is older and which is newer. The script this was generated with(2) is here: http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/bibisect and I sincerly wish it is worth the carbon footprint needed to generate the output in the last days. ;) So I hope with this, we make regression finding some more fun and allow us -- QA and developers together -- to stabilize this release more quickly that ever before. If there are questions about how bisecting works, I am pretty sure developers will be happy to help out people interested to get started as this allows us to distribute the work on more shoulders. Opinions/Comments? Best, Bjoern (1) Not quite for 3.4-3.5 as the stuff as is only works from the point in time, where we merged repositories, but from the merge point (early August 2011) to the point of 3.5 branchoff (early December). (2) Almost: I forgot to disable-oolink, so I had to filter the branch to tweak the links again. :-/ _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
