QA/Bibisect/Bibisectzilla

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Bug Report
• Bug Triage
• Projects
• Regression Test
• Automated Tests
• Bibisect
• QA Meetings
• QA FAQs

• EN
• AN
• AR
• AST
• BE
• BG
• BN
• BRX
• CA
• CS
• DA
• DE
• EL
• EO
• ES
• ET
• FA
• FI
• FR
• GD
• GL
• GUG
• HE
• HI
• HR
• HU
• ID
• IS
• IT
• JA
• JV
• KO
• KU
• LO-LA
• LT
• MN
• MR
• NE
• NL
• NO
• OC
• OM
• PA
• PL
• PT
• PT-BR
• RO
• RU
• SAH
• SK
• SL
• SQ
• SV
• TA
• TE
• ไทย (TH)
• TR
• UK
• UZ
• VI
• 正體 (ZH-TW)
• 简体 (ZH-CN)
• Article Title: QA/Bibisect/Bibisectzilla

This page was marked as inactive and is retained for historical reference. This information is obsolete

This page is about Bibisectzilla, our plan to merge all of the GNU/Linux Bibisect repositories into a single repository.

Overview

Bibisecting a bug is a useful way to track down which commit introduced the problem. Our current bibisect repositories have a couple of drawbacks:

• They aren't updated automatically/daily
• There are multiple repositories covering different (sometimes overlapping) commit ranges
• We don't have any repositories covering the pre-3.5 era

The Plan

After discussion in QA, we're moving forward with a plan to create a single repository with these features, nicknamed Bibisectzilla:

• Updated daily (or on a regular schedule, e.g. every 60 commits)
• May be updated via git commands
• Spans LibreOffice history back to pre-fork era
• (Restriction: Only available for 64-bit GNU/Linux systems, due to our existing bibisect repos)

Progress

Complete coverage will require a few steps:

• [PLANNED] - A TDF-controlled buildbot that automatically shoves builds into a git repo (Cloph)
• [PLANNED] - Combine builds from existing bibisect repos with other builds (including a pre-fork OOo build) into a single repository (Robinson)
• [PLANNED] - Combine git repo for TDF buildbot with Robinson's repo (Robinson, Cloph)

Coverage

In an ideal world, the Bibisectzilla repository would have daily builds starting pre-fork and continuing (without interruption) through the current day. We do not have bibisect repositories for LibreOffice before the 3.5-era, and the build system of that time was so complicated (I've been told) that it's probably not worth it for us to try to resurrect it to generate (new) builds.

The builds we do have available to us include:

• Bibisect repos (some/all of which are 64bit-only)
  • 4.0 - Bjoern
    • 3.5 - OLD (included in 4.0)
    • 3.6 - OLD (included in 4.0)
  • 2013-10-12 - Bjoern
  • 4.0+ - Canonical (but Bjoern can help?) (Note: This repo has some problems)
  • Miklos has a bibisect repo (perhaps one of the above?? - see email)

• Individual builds
  • We have some on the Download server, I believe
  • The last pre-fork OOo build (which I believe is OOo 3.2.1)
    • http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.2.1/
  • We have release builds for 3.3.0, 3.4.0 (which I believe are right on the master branch, so should be reasonable to include)

Reasonable Coverage

Per chat w/bjoern, adding

Bibisect#Versions:

• 4.0 (MELD_LIBREOFFICE_REPOS to 8450a99c)
• 2013-10-12 (4b9740b4 to cb4e009c)
• 2013-11-25 (90830788 to 1581b1fc)

We'll add more builds later, and then hook it up to the daily builder

Hurdles

• We're going to end up with a really big repo => Lots of data for users to download
  • Because the git protocol can't resume failed clones/downloads, I suggest that we have users download the repo via HTTP first, then have them update via git
  • Suggest that we have a separate git branch for each version, since git has support for downloading only a single branch worth of data

• How will big gaps in our build history affect our effectiveness?
  • If someone does uncover old builds or generates old builds, we could add those to bibisectzilla...