Bugmasters/Projects/Bugzilla Training/Bugmasters/Projects/Bugzilla Training/Tutorial

From MozillaWiki
Jump to: navigation, search

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
        1. Log out
        2. Request a password reset
        3. Reset password and log in
        4. Enable 2FA
  • 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?
    • 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

Dealing With People Issues

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.

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.

Bug Guidelines

  • Mozilla Bug Guidlines
  • What do good bugs need?
    1. Right Component
      • When In Doubt, Ask
      • Look at stack traces to chase down components
    2. Steps to Reproduce (STR)
      • Do you have or need steps to reproduce, check the flag.
    3. Regression Range (if a regression)
      • Use MozRegression
      • Cut and paste result as comment
      • No time to run MozRegression, add the regressionwindow-wanted keyword
    4. 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
    5. Platform
      • If bug is specific to OS and version, set the architecture and OS flags
    6. Whiteboard
      • Your team may have whiteboard tags you use
      • Consider converting those to keywords
    7. 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)
    8. User Story
      • If this a feature request, enter a user story (X should be able to Y because Z)
  • 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

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

See Also

Retrieved from "https://wiki.mozilla.org/index.php?title=Bugmasters/Projects/Bugzilla_Training/Bugmasters/Projects/Bugzilla_Training/Tutorial&oldid=1170969"