QA/Bugzilla/Gardening

From The Document Foundation Wiki
< QA‎ | Bugzilla
Jump to: navigation, 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.

Introduction

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.

Automation

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) 2017-02-11T19: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)
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started

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)

2014

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

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

Running

  • 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.

Running

  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'
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/REOPENED#Criteria
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

Running

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.

Running

  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.

Running

  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

Task: Cleaning-out NEEDINFO

Frequency Every month
Purpose Bugs shouldn't sit in NEEDINFO for ever. If they are untouched for 6 months, we will plan to close them (and then close them, a month later) as INSUFFICIENTDATA.
Last completed - Stock Message X1sc0 (talk) 2017-12-04T12:46:41 (UTC)
Last completed - Stock Follow-up Message X1sc0 (talk) 2017-12-04T12:46:41 (UTC)

Running

More background information: QA/Bugzilla/Fields/Status/NEEDINFO

Steps:

  1. Find NEEDINFO bugs that haven't changed in 180 days
    • Pick a few bugs and take a quick look to make sure that everything looks kosher
    • Exclude: EasyHacks
  2. Update the ID to match the day the action is done at the end of the message
  3. Perform the bulk-update:
    • Point users to the NEEDINFO page
    • Request information again
    • Let user know that if requested information is already there, to appropriately set the status of the bug so we move the bug forward

Notes

It would be a good idea to use the QA Administrators account for this update.

Cleaning-out NEEDINFO: Stock Message

Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.

For more information about our NEEDINFO policy please read the
wiki located here:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO

If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
 
Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-NeedInfo-Ping-20171204

Cleaning-out NEEDINFO: 30 days later

30 Days after the first notification:

  1. run 'python3 qa-tools.py massping' to see the bugs that need to be pinged
  2. Update the ID to match the day the action is done at the end of the message
  3. Bulk-update:
    • Close the bug as INSUFFICIENTDATA because of lack of information
    • Let user know that if they are still experiencing the bug they can open it back up as UNCONFIRMED if they provide requested information

Cleaning-out NEEDINFO: Stock Follow-up Message

Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-20171204