[Libreoffice-qa] Bibisect Roundup

[Robinson Tryon]

On Thu, Dec 12, 2013 at 5:33 PM, Pedro <pedlino at gmail.com> wrote:
> Hi Robinson
>
> I'm not sure I understand this bibi stuff but isn't it easier to have a user
> friendly version that just runs the last release of each branch (actually
> that is what I do with portable versions under Windows)?

What kind of search pattern do you use?

> Then when the branch is located, run the final version for each release.
> This would give you the subversion.

do you mean the commit hash?

> If the bug/regression is located between two subversions then run each
> release (betas, RCs or dailies if available)
>
> The first two steps are quite easy and at the moment should take around
> 2-3Gb each (6 versions x ~350Mb)

The basic plan with bibisect is to do a binary search[1] on a set of
builds listed in chronological[2] order. We can find the culprit
commit or commit-range very quickly, which is why it is such an
effective search technique.

>
> The last step could be left for the advanced QA people :)

My suggestion regarding improvements to bibisect are based on my
conversations w/Bjoern and Norbert, and are, essentially:
1) Use 2 levels of binary search trees to improve performance
2) Put a simple interface on it to
  (a) Make it easier to use the tool
  (b) Reduce user-error

By the time we're done with the GUI, I hope that bibisecting a
regression will be easier than triaging a bug.

Cheers,
--R

[1] https://en.wikipedia.org/wiki/Binary_search_algorithm
[2] It's actually more like "order in which they were committed," but
"chronological" is close enough for our purposes.