QA/Bugzilla/Development

e

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

This page provides some information about our ongoing Development, theming, and modification of Bugzilla.

Code

The source code for Bugzilla and our local templates, etc.. all lives in a git repository here:

• https://gerrit.libreoffice.org/#/admin/projects/bugzilla

To get the code and contribute changes, you'll need a Gerrit account. The Gerrit wiki page has some information specific to contributing to LibreOffice core, however nearly all of the information is also relevant to contributing to Bugzilla.

• Before you contribute, we'll need a license grant for you. Given that the Bugzilla code is MPLv2, we can probably just re-use the same blurb style as we use for LibreOffice developers. If we want to be specific, we can have people email to the QA/Mailing List:

All of my past & future contributions to TDF Bugzilla/Bugtracker
may be licensed under the MPLv2 license.

Then use your specific gerrit url to clone the repository. It'll look something like:

ssh://<your-username>@gerrit.libreoffice.org:29418/bugzilla

Making commits

We'll need to grant you access, review your commits, etc.

All of our commits are done on top of a given Bugzilla version, e.g. 4.2.3. We'll create a branch 'tdf-4.2.3' that will include the Bugzilla 4.2.3 tag, and then build on top of that version.

Ask Robinson or Norbert for more information.

Keeping Bugzilla up to date

Upgrading Bugzilla is pretty straightforward. The gitk tool will help you keep track of branches and tags. Run it like this, somewhere inside the git repository:

gitk --all&

Setting up the repo

• Get a clone of the TDF Bugzilla repository from gerrit:

ssh://<your-username>@gerrit.libreoffice.org:29418/bugzilla

• Add a remote for the Mozilla upstream:

git remote add upstream https://git.mozilla.org/bugzilla/bugzilla.git

• Edit some branches in .git/config to point to upstream instead of origin:

# Note: We could probably get away without this, as we only build on top of tagged versions
 [branch "master"]
     remote = upstream
     merge = refs/heads/master

• Update the remotes

git remote update

Creating a new branch

To create a new branch, we'll first check out a particular version of Bugzilla, e.g. 4.4.6

git checkout bugzilla-4.4.6

Make sure in gitk that everything looks kosher, verify that the working directory, index, etc.. is all clean:

git status
 git branch

Create the TDF branch

git branch tdf-4.4.6

Now we need to port all of our local changes to that branch. Some might use the term rebasing, but because we'll want to keep our existing TDF branch (e.g. tfd-4.4.3, etc..) intact for historical/backup purpose and just copy over the relevant commits, we'll use git cherry-pick:

git checkout tdf-4.4.6
 git cherry-pick <first-branch-commit>^..<last-branch-commit>   # See [https://stackoverflow.com/questions/11835948/git-cherry-pick-vs-rebase/14072763#14072763 example here]

This process might work or might fail in various interesting ways. Remember that some changes might be incorporated into upstream, at which point we may want to remove them from our local changeset.

Once we're happy with the updated branch, add a new line to the top-level README.TDF file:

emacs README.TDF

We can either test the new branch locally, or we can push it up to the git remote and try it out on our test VM:

git push --set-upstream origin tdf-4.4.6   # ''This pushes the content up to origin and sets the remote''

Dependent Services

Several TDF services are dependent upon Bugzilla, sometimes even modifying/editing bug reports. When we upgrade Bugzilla, it's important for us to test to make sure that our services will migrate properly along with the upgrade.

Gerrit

TODO: Document how we should test integration

TDF Wiki

The wiki interacts with Bugzilla in a couple of different ways.

• Templates like, e.g. {{tdf}}
  • see complete documentation at Template:bugentry
• Easy Hack bugzilla rss feeds
  • like at Get Involved/Wiki
  • all EasyHacks pages listed at Category:EasyHacks

ESC Bugzilla Stats Script

Used weekly for the ESC minutes, this script pulls out some juicy tidbits about Bugzilla.

Located in the dev-tools repository:

 https://gerrit.libreoffice.org/#/admin/projects/dev-tools

To check changes against the test server, change:

$bugserver = "bugs.documentfoundation.org";

to this:

$bugserver = "bugzilla-test.documentfoundation.org";

And then execute it in the terminal:

./esc-bug-stats.pl

When testing some changes to Bugzilla, etc., make sure that the script gives you some reasonable output, e.g.:

...
...
* Bibisected bugs open: keyword 'bibsected'
	+ 244 (of 649) older ?
		+ http://bit.ly/VQfF3Q

* all bugs tagged with 'regression'
	+ 443(+?) bugs open of 3404(+?) total 22 high prio.

	* ~Component   count net * high severity regressions
	        Writer -  4 (+?)
	   LibreOffice -  3 (+?)
	  Installation -  1 (+?)
	            UI -  1 (+?)
...

Git-Bugzilla Script

This is the domain of moggi (Markus Mohrhard).

Simple testing can be done locally, against our test bugzilla. Markus writes:

https://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/ciabot/libreoffice-bugzilla2.py
with the configuration https://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/ciabot/config-example.cfg

External Dependent Services

Beyond our internal tools, some external tools rely upon our bug tracker as well, including

• Launchpad
• and probably other tools...