Bugmasters/Projects/Bugzilla Training/Bugmasters/Projects/Bugzilla Training/Tutorial
From MozillaWiki
< Bugmasters | Projects | Bugzilla Training
Contents
How Do I Bugzilla?
Don't Panic in Large Friendly Letters
Bugzilla is a thing that evolved over time. It has layers. This class is not enough time to cover everything.
Bugzilla is a bug database.
Bugzilla is not Jira, GitHub, or Greenhopper and does not try (at the moment) to apply heavy process.
Account Setup
- Bugzilla Accounts?
- Do you want to use your existing account (and don't mind getting work-related emails in your personal email box?)
- Set your existing bugmail as your bugmail field in phonebook
- Create a new bugzilla account
- Set that as your bugmail field in phonebook
- Don't use GitHub to auth
- Enable Two Factor Auth
- Install Duo on your phone (or other 2FA solution)
- Two Factor Auth Requires a Bugzilla Login
- If you have been using GitHub
- Log out
- Request a password reset
- Reset password and log in
- Enable 2FA
- Do you want to use your existing account (and don't mind getting work-related emails in your personal email box?)
- Make your name in Bugzilla useful (real name? pffft)
- Name That You Go By In Mozilla Contexts [:irc handle] (Timezone Relative to UTC) NEEDINFO? me
- Example: Kara Danvers (she/her) [:supergirl] (UTC-7) NEEDINFO? me
- Do you have the proper permissions?
- Can you EDITBUGS?
- You can request that permission, but note Mozilla Employees get this permission by default.
- If you are a Mozilla Corporation employee, can you see those bugs restricted to Mozilla Corporation employees?
- If you have mozilla.com address, yes.
- If you don't then you need to go to phonebook and update the "Bugzilla Email" entry.
- Security Bugs
- Access limited to security groups, Mozilla staff do not see these by default
- If you need access to security bugs, you will need to be seconded to the groups, the process for that is handled by Daniel Veditz
- Can you EDITBUGS?
Dealing With People Issues
- https://wiki.mozilla.org/BMO/comment_tagging
- Comment tagging can hide obsolete, irrelevant, spam, and abusive comments
- A better anti-abuse policy is underway
Riding the Trains
- Run Nightly as your main browser
- Learn how to use profiles for debugging
Bug Lifecycle
- Pixar Joke Goes Here
- Bugs filed by new bugzilla users, or bugzilla users without EDITBUGS start in UNCONFIRMED
- Softvision (our contractors) and volunteers triage bugs to verify and land in the right component
- Bugs should be moved out of UNCONFIRMED within 5 business days of filing
- Bugs in UNCONFIRMED move into NEW, or get RESOLVED
- Other bugzilla users' bugs start in NEW
- Bugs can be resolved as closed
- INVALID: spam, trolling, glitches in matrix
- INCOMPLETE: missing information, such as reproduction steps
- DUPLICATE: another bug describing this exists
- WORKSFORME: can't replicate the bug
- WONTFIX: it's a bug, but we wont fix it
- Or they go on
- ASSIGNED is a state that doesn't have a lot of meaning outside of a team
- This is a theme, lots of metadata on bugs only takes on meaning in a team-specific context
- Bugzilla + Folk Knowledge = process
- a bug will probably not enter ASSIGNED, but you'll know there's code for it if you see a review flag set for it
- RESOLVED:FIXED bugs are bugs with reviewed patches, that have been landed on the Mozilla Central tree by a Code Sheriff
- Not all RESOLVED:FIXED bugs are moved to RESOLVED:VERIFIED, but those which are have been confirmed
- REOPENED bugs are bugs that had been RESOLVED, but reopened.
- Bugs filed by new bugzilla users, or bugzilla users without EDITBUGS start in UNCONFIRMED
Note well, there are other paths through bugzilla, for non-Firefox, non-Mobile, non-Connected Devices, non-Platform things. Because bugzilla is a task tracker as well as a bug manager.
See also Bugzilla's documentation.
Bugspace
Bugzilla's hierarchy and the Mozilla project's hierarchy are non-congruent.
- https://wiki.mozilla.org/Modules/Core
- Leadership/Direction
- https://wiki.mozilla.org/Bugmasters/Project/Bug_Handling/Triage_Leads
- People looking at inbound bugs
Bug Guidelines
- Mozilla Bug Guidlines
- What do good bugs need?
- Right Component
- When In Doubt, Ask
- Look at stack traces to chase down components
- Steps to Reproduce (STR)
- Do you have or need steps to reproduce, check the flag.
- Regression Range (if a regression)
- Use MozRegression
- Cut and paste result as comment
- No time to run MozRegression, add the regressionwindow-wanted keyword
- Version Flags
- There's a version field in the enter bug flow, but using the version flags will provide more information to triagers and release management
- Platform
- If bug is specific to OS and version, set the architecture and OS flags
- Whiteboard
- Your team may have whiteboard tags you use
- Consider converting those to keywords
- Keywords
- Use regression, dataloss, crash, and topcrash as appropriate
- crash and topcrash are usually added when you file from Sirocco (the crash reporing app)
- Your team may have specific keywords you should use
- Please document them (see https://bugzilla.mozilla.org/describekeywords.cgi)
- Use regression, dataloss, crash, and topcrash as appropriate
- User Story
- If this a feature request, enter a user story (X should be able to Y because Z)
- Right Component
- Flags that aren't useful at bug creation
- Severity
- Use the regression, dataloss, crash, and topcrash keywords instead
- Priority
- unless you're involved in triage for the component and know where it belongs don't set it
- Target Milestone
- Release management watches release flags
- Sheriffs set this field when merging patches
- You can propose a release flag (this will be gone over by RelMan team in their tutorial)
- Votes
- This field is not used
- Severity
Queries
- How To Find Bugs in Your Component
- Quick Search
- Searching on Flags
- Searching on Changes
- Using the API
- Caveats
- 500 bugs limit default
- 10,000 bugs max
- Use Reports to partially get around this
Watching
Reporting
- The form a Bugzilla user sees depends on who they are
- This affects how bugs are reported