[Libreoffice-qa] [bjoern.michaelsen at canonical.com: [Libreoffice] What is bibisect? And what is it doing in my office?]

[Bjoern Michaelsen]

Hi there,

just a short forward of this little post on the developer list, which might be
very interesting for QA guys too.

Best,

Bjoern

----- Forwarded message from Bjoern Michaelsen <bjoern.michaelsen at canonical.com> -----

Date: Fri, 9 Dec 2011 14:59:53 +0100
From: Bjoern Michaelsen <bjoern.michaelsen at canonical.com>
To: libreoffice at lists.freedesktop.org
Subject: [Libreoffice] What is bibisect? And what is it doing in my office?
User-Agent: Mutt/1.5.21 (2010-09-15)

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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

----- End forwarded message -----