Firefox Engineering Meetup
Developers who are involved or interested in contributing to the Firefox codebase.
Help engineering contributors become more effective through understanding the development environment and architecture of the codebase.
Ideally these are communicated to attendees as early as possible before the event.
Getting Set Up
To get started, you don’t need much more than a computer than can run Firefox and an email address.
- Make a bugzilla.mozilla.org account, and confirm it through email.
- Set your bugzilla preferences to use the experimental UI (bottom of the page.)
- Use that email to sign up for the bugmasters mailing list.
- Download and install Firefox Nightly.
- Set up a testing profile in Nightly; this helps keep your bug triage work separate from your personal profile. Setting the “experimental user interface” to “on” will make your life better.
There are several different areas of focus for an event. These are:
- Bug triaging
- Bug fixing
Finding Bugs To Triage
The first thing to do is sign up for TriageBot
Our triage robot will send you a small number of bugs to look at, daily or weekly, as you like. You will also have the option of checking the “I can help reproduce bugs”, and “I can help find regression ranges” - if you did that, would be very helpful!
If you’d like to start taking care of a Firefox component in Bugzilla, you can log into Bugzilla and follow this link to pick a component to watch:
If you’d like to do this, please email Mike Hoye and let him know; there are a lot of options to choose from and not all of them are still active, still useful or good places to get started. Mike would like to help you find a component needs help, and deserves your time and attention.
You probably won’t be able to help every bug you see, and that’s OK. We’re grateful for the time and effort you can offer, and every bit helps. If you have questions about what to do with a bug, email the Bugmasters mailing list, where we can discuss it together.
Helping sort the bug into the right component, and setting the right keywords and flags, are the most important early steps in a bug’s lifecycle. It is very helpful to make sure bugs have the following:
- Can we move an untriaged bug into the right component?
- Search that component for duplicate bugs - do we have a bug that looks similar? Add a comment saying so.
- Can we ask the reporter to recreate the bug:
- If the bug is described as something that used to work, or broke following an update, add the “regression” keyword.
- If the problem is described, make sure the “crash” keywords is added, and ask the reporter if they can open about:crashes and add a link to the most recent crash signature.
- Clean up the Tracking and Details flags if you can, particularly the Platform, “Has STR” (Steps To Reproduce) and “Has Regression Range” flags.
As you gain experience, you’ll learn about what questions to ask bug reporters, how to find duplicates and what to do next. In the beginning, just helping set some flags and ask some questions will go a long way.