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. :-/
Context
- [Libreoffice] What is bibisect? And what is it doing in my office? · Bjoern Michaelsen
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.