Welcome

Welcome to the highly frustrating yet satisfying world of Bug Triage for Mozilla based software. Before we go on, I would like to warn you about some of the dangers involved. Firefox is big and multi-threaded. When you throw in a flash player, a java virtual machine, and a couple of plugins, it gets bigger. The whole Firefox vs. Iceweasel issue will also make your head spin.

Yet, Firefox is a very visible piece of Ubuntu. So, the significance of what you are doing is great. Helping fix a issue in Firefox is helping thousands of people.

Administration

Here are a couple of long term goals for Firefox triage.

1. Every 'unconfirmed' issue report should be acknowledged with in a few hours. In many cases a Firefox crash report is the first bug report that a new users files. Let's make it a positive experience.
2. Issue reports that have been sitting as 'need info' should be closed or followed up on after 30 days.
3. All 'confirmed' bugs should be classified as Ubuntu, Debian, or Mozilla based on where in the packaging processing they first appear. Debian and Mozilla issues should be pushed upstream as soon as possible. Ubuntu issues should be taken care of by an Ubuntu Developer

Versions

At any given point in time we will be triaging 3 versions of a package. Those found in an up to date Long Term Support (LTS), Current, and Current +1 release. These versions must be installed from the official Ubuntu repositories. If someone reports a bug from a third party repository, politely refer them back to the repository maintainer for support.

1. LTS- We will fix all issues that have been rated High by QA. We will work with the various support channels to develop work a rounds for other issues as need.
2. Current - Same as LTS.
3. Current +1. We will attempt to fix all issues.

Upstream

Our direct core upstream is now the Mozilla Foundation, this was changed as per Feisty Fawn, anything before Feisty it is Debian, this was changed due to trademark issues, MozillaTeam/Trademarks.

Once the report has enough information we usually send it back to the original code developer(s), we do this because we cannot fix every bug we receive as we wouldn't have much time at all, this is known as sending it upstream.

When doing this you have to keep in mind that sending a report upstream is designed to speed up the process of bug fixing, thus sending insufficient and/or incorrect information helps nobody, (please, please ask if you are stuck), once you have enough information select the correct upstream tracker, a report the bug yourself, please see this entry for more detail.

Debian

• Debian

Mozilla

• Mozilla

Java

• Sun Java

• GNU Classpath (GCJ)

Flash

• Adobe Flash

• GPL Flash

• Gnash

Common Issues

As a triager, you will begin to see a number of re-occurring issues.

User Interaction

MozillaTeam/Bugs contains step-by-step instructions for bug reporters to provide us with helpful bug reports.

Crashes

New to the Edgy development Cycle is the apport crash reporting infrastructure. This infrastructure is currently undergoing rapid development so hold on tight. We'll talk in more detail about crash report later on. For now, let's just consider that most Firefox crashes are actually Flash, Java, or plugin related. Please realize crash reports are not always bug reports.

Mozilla Gtk Consistency

Firefox is written to be cross platform. The Mozilla developers have developed their own widget set to aid in this cross compatibility. Widgets are all the dialogs where Firefox communicates with the rest of the operating system. Such as file pickers, file save, set proxy.... For consistency with the rest of Ubuntu, these widgets have often been replaced with Gtk widgets by Debian and Ubuntu Developers.

Localization

Upstream Firefox is officially available in over 45 languages. That is a lot of different fonts and localized Ubuntu help pages to keep straight.

Branding

Upstream, Mozilla is struggling with how to protect the Firefox brand while being as flexible as possible to downstream distributions. This causes changing icon and product naming requirements.

Prepared Responses

As a triager you will often be asking the same types of questions. I have compiled a list of my frequently asked question at MozillaTeam/Bugs/Triage/Responses. It works pretty well to copy the generic responses to a Tomboy note and tweak them to better fit you personal style. Always try to include the reporters name and a personal sentence to each response. I like to click on the reporters name and check out their karma to get a feel from their experience with bug reporting.

Triage process

I've developed these processes over the last several weeks while wrestling with Firefox.

First Responder (Great place to get started triaging)

When a bug first comes into Launchpad, we need to look them over to make sure that they are correct and complete. Untriaged bugs can be found by going to https://bugs.launchpad.net/people/mozillateam/+packagebugs and looking for unassigned bugs.

Assign Package

First we want to make sure that the bug has been assigned to the right package. If in doubt leave it assigned to Firefox. As more information comes in, we can always assign it to another package.

Assign Status

We need to work with the reporter to gather useful information to diagnose the issues. The easist way to do this is to reproduce the issue. Start by asking the reporter for step by step method of reproducing the issues. See if you can reproduce it on your machine.

I like to create a couple of virtual machines to match common configurations. Then, as I talk to the reporter, I set up one of the virtual machines to match the reporters. Information to ask for--

• Ubuntu Distribution. Firefox version.

  • Type  firefox --version  on the command line.

  Types and versions of flash player. Types and version of Java.

  • Enter  about:plugins  in a firefox address bar. Goto File->Save Page As. Upload 'About Plugins' as an attachment.

  Crash Report.
  • Crash reports can be found in /var/crash.

It will take a little experience to learn what information is needed. While you are actively having a conversation with the reporter set the status to Needs Info. If you have gathered enough information to reproduce the issue set the status to confirmed. If you can not reproduce the issues set the status to Unconfirmed.

Assign Bug Reports

All issues should be assigned to "mozillateam" by default, this is part of our bug triage policy and please try to follow it as best as you can.

Tagging a Bug Report

As a team, we have decided to use a tagging library to that we can better organize our bugs. Please see MozillaTeam/BugTags for our current library. Since we have hundreds of bug reports we use various tags to organize them. For example the "traced" tag will let the team know that the bug report has debugging symbols, a full crash report, and a stack trace associated with it. As we grow as a team, we are looking to add other tags, such as "accessibility". However, we request that if you are triaging a bug please use only the tags in the library as the team must decide on any new tags.

Subscribe to Issues

If you are interested in following up on the issue subscribe to the issues. If you have set the status of a bug to "Needs info" please subscribe to it so that you can complete the information gathering dialog with the reporter.

Unconfirmed (The fun ones)

Unconfirmed Bugs These are the Red Headed Stepchildren of the bugs world. They are the issues that we can not yet reproduce or prove even happen. They are fun to pick and poke at when you have a few minutes. Every few days I like to randomly work on a few of these. After a while you will start to see patterns to solve them. They can be like those pictures were you have to unfocuse your eyes to see the ship. You can't worry about it. Sometimes you see the ship and sometimes you don't.

Needs info

Bug reports may lack some information. Triagers ask for more information from the bug reporter in order to further diagnose the problem, and set the status to "Needs Info". If you see that the bug reporter did not provide the requested information in a month or so, close the bug with a respectful message:

Your bug lacks information we would need to investigate further. We
are now going to close the bug - please reopen if you have more
information at hand.

Source

Confirmed (Name dropping for Nerds)

At this point we have to make a decision. Patch it, or push it upstream, provided that we are sure it is not specific to Ubuntu and that we can not patch it ourselves.

CategoryMozillaTeam, CategoryBugSquad