I’ve not used RH Bugzilla much, and want to learn from my limited exposure to save time later. That’s what this post is for: it will be updated and change in the future.

Searching for existing bugs

You’re looking for a recent bug; such as a misbehaviour in a package you’ve just upgraded to.

• Use the bugzilla number as a proxy for recently raised tickets, as they’re doled out in sequence.
• This applies equally well to basic or advanced searches; perform the search and then use the column sort in the results.

You know exactly where the bug is, down to the sub component level.

• When using advanced search, you can drill right into a product; eg:
  • a specific version of RHEL (product)
  • a specific package (component)
  • a specific function or binary (sub-component)
• When raising a bugzilla, if you know this level of detail, then complete those fields. But when searching, don’t assume all the fields are filled out, and if you specify the sub-component, it won’t find tickets with that not completed.
• Specify the product (eg: RHEL7) and component (package) but don’t go further, and if you still can’t find the bug, you may need to be less specific.
• Narrowing down all the bugzillas roughly (eg: to RHEL7) and then using the text search for commands, daemons, service names, kernel modules, etc. is an alternative approach to netting the ticket you’re looking for, albeit the signal:noise ratio might not be great.

Closed bugzillas.

• If the bug has been there a couple of months, chances are you’re not first, and if you know its not been fixed, it makes sense to look for open tickets.
• However, some bugzillas may have been raised by the developers or by customers that have been closed as duplicates, and in the former case, the fields are more likely to be all filled out.
• Include closed tickets in the search, start as specifically as you can and then ‘zoom out’.
• Use the ticket sort to find recent tickets.
• Assuming you’re looking for a single bugzilla for the bug you’ve found (ie: the developers have closed all the dupes) then including the closed duplicates in the search results rather increases the chance of tracking it down.

Make use of the bugzillas you didn’t want to find.

Use ‘show other bugs’ on other tickets

• Next to the sub-component field, there’s a ‘show other bugs’ link.
• While doing searches for your bug, if you find a bugzilla with the right sub-component filled out, use the ‘show other bugs’ link.
• The search results are quite good, finding relevant bugzillas even when those tickets don’t have the sub-component field filled out.
• There’s nothing obvious from the search parameters why it’s better, though It does include closed tickets, see above.

Use the ‘wrong’ bugzillas to identify helpful debugging output.

• Make note of the commands and output that developers requested to troubleshoot similar tickets, or bugs in the same part of the OS.
• If you end up raising a bugzilla, you can proactively provide the information they might otherwise ask for.

Info about Bugzilla tickets.

zombie apocalypse

• good overview of what the various fields are used for, and the lifecycle of bugzillas.

opensource.com

• similar guidance on how to use bugzilla, by David Both.

fedora – bz ticket states

Redhat – bugzilla ticket states, and definitions for other fields.