QA/Bugzilla/Development

    From The Document Foundation Wiki
    < QA‎ | Bugzilla

    e


    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:

    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
    

    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.

    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