From The Document Foundation Wiki
< QA‎ | Bugzilla
Jump to navigation Jump to search

This page is about the Gardening of Bugzilla, including periodic maintenance, small cleanups, and automated tools. See QA/Easy_Hacks for QA tasks with a broader scope.


Like thatching a lawn or pruning an orchard, it's important to do some periodic maintenance on our Bugzilla install lest it become overgrown, tangled, and unusable by QA or developers. Gardening includes a number of different areas:

  • Periodic maintenance
  • Cleaning up Fields
  • (and more)

Gardening and Bug Triage complement each other. The more that our QA/Team learns about triage and gardening of Bugzilla, the more effectively we can stay on top of all of the reports in the bug tracker.


Many of the Gardening tasks have been automated now.

Bugzilla Administration

There may be some task overlap with Bugzilla Administration, but many tasks are outside the scope of Gardening:

  • Dealing with user account creation/deletion
  • SPAM
  • Harassment
  • Deleting Attachments (only happens in rare cases)

Task: Remove commas from the whiteboard

Frequency Ideally, at least once a month
Purpose Tags in the Whiteboard are space-delimited. Commas don't belong in this field.
Last completed Buovjaga (talk) 2018-06-19T12:00:00 (UTC)
  1. Find bugs with a comma in the Whiteboard
  2. Remove the commas and leave a comment with this message:
Removing comma from Whiteboard (please use a space to delimit values in this field)

Task: Use proper markup in the Whiteboard

Frequency Whenever
Purpose Tags in the Whiteboard should follow our Markup Guidelines. We can update tags to harmonize our usage.
Last run

(we're never going to 'complete' this one)


Generally speaking, we want people to follow our Markup Guidelines, including

  • Separating tags with spaces
  • Using "wimpyCaps"
  • Not writing sentences in the Whiteboard!


  • Query for LibreOffice bugs
  • Bugs usually need to be updated one at a time
  • Some tags are ALL CAPS (e.g. the BSA)
  • Note that many searches are case-insensitive, so searching for "bsa" in the Whiteboard (even in a regexp) seems to return hits for "BSA" and "BsA" as well.

Task: Monitor REOPENED bugs

Frequency ~ Every 3 months
Purpose The REOPENED status is reserved for bugs that were thought to be FIXED. It is sometimes used mistakenly in other contexts.
Last completed Buovjaga (talk) and Yousuf Philipz (talk) 2016-10-21T15:43:27 (UTC)

For more details, see QA/Bugzilla/Fields/Status/REOPENED

In Bugzilla, Status: REOPENED has the technical meaning that a bug is:

  1. Assigned
  2. The assigned developer said they fixed it
  3. Someone has reproduced the problem on a version which, according to the developer, the problem should not appear.


  1. Query for all bugs with REOPENED status
    • (It's a short list -- only 27 as of 2014-12-30)
    • TODO: Each time you run the query, edit it and update the status-last-changed-date (at the bottom of the page) to be 1 day before the Last Completed date. That way you won't review any REOPENED bugs that the last reviewer already verified as legitimate.
  2. Review each bug manually and determine if the bug meets the criteria specified above.
    • If you have time, try to reproduce the bug to see if it can be RESOLVED WORKSFORME
  3. If a bug doesn't meet the criteria for REOPENED, change the status appropriately. Feel free to leave a comment such as:
Bug does not meet the criteria for Status 'REOPENED'
Status -> (whatever status is appropriate)

Task: Cleanup Backport Requests

Frequency ~ Every 1 month
Purpose Bugs with Whiteboard tag backportRequest:X.y need some TLC to make sure they have the right Status, Whiteboard and Keyword tags, etc..
Last completed X1sc0 (talk) 2016-11-30T09:42:13 (UTC)

For more information, refer to QA/Bugzilla/Fields/Whiteboard/Advanced and QA/Bugzilla/Fields/Status/RESOLVED#Fixed_in_a_newer_version


QA/Bugzilla/Useful_Queries#Backport_Requests gives two lists:

  • One for bugs that need to be reverse-bibisected
  • One for bugs that are ready for devs to address (reverse-(bi)bisected or otherwise have a commit identified)

On both lists, all bugs should have status RESOLVED or CLOSED

  • For each bug, confirm (via testing or reading comments) that the bug is fixed in the latest version or master branch
  • Follow guidelines here to set the Status and Whiteboard tags
  • If a bug has been fixed in branch X.y (in a release, beta, or daily build), then any backportRequest:X.y tag should be removed from said bug

Task: bibisected, bisected or bibisectRequest keywords not tagged with regression

Frequency ~ Every 3 months
Purpose Bugs with keyword bibisected, bisected or bibisectRequest need to be evaluated for regression.
Last completed X1sc0 (talk) 2016-11-12T13:40:24 (UTC)

For more information, refer to QA/Bugzilla/Fields/Keywords.


  1. Find all bugs with keyword bibisected, bisected or bibisectRequest but without regression Keywords: Query
  2. Check each bug report manually to determine if it is regression ( important to check the history to see if someone remove the keyword in the past )
    • If it is, add Keyword regression

Task: Regressions not tagged with (bi)bisect

Frequency ~ Every 3 months
Purpose Bugs with keyword regression need to be evaluated for (bi)bisecting. Even if they can't be bibisected, they need to be marked with Keyword preBibisect.
Last completed X1sc0 (talk) 2016-09-20T16:13:09 (UTC)

For more information, refer to QA/Bugzilla/Fields/Keywords and QA/HowToBibisect.


  1. Find all bugs with keyword regression but without any 'bibisect*' Keywords ( Exclude bugs that have been bisected too):
  2. Check each bug report manually to determine if it is bibisectable
    • If it is, add Keyword bibisectRequest
    • Otherwise, if the bug is outside the bibisect range, add Keyword preBibisect