This is a page for beginners written by a beginner with help from The Mozilla Team members.

Introduction

Bugs (problems) with Mozilla programs are managed by Launchpad. This makes sorting these out easier as it is a central place for people to go to. The bugs are posted when users come across them and then they need to go through the process of triage and fixing. Bugs need to be triaged to find out if they are down to a problem with the software which can then be sorted or another reason. Sometimes more than one person will file a bug for the same problem, in this case the duplicate bugs need to be found and marked as duplicates. This will prevent people wasting their time fixing something that someone else has fixed.

There is a program that can be used to help find these duplicates. It is called BugHelper. Instructions for installing it are at getting-started

Bughelper searches the bugs that are on Launchpad and lists them in the terminal. You can specify the criteria for the search to only get the results you need. More instructions are found here.

Bug flow

We use status and tags to identify what stage the bug is in. To change a status of a bug you need to click on the package name (found under Affects at the top of the bug page on Launchpad) and use the dropdown box Status to select the new status. To change a tag click on Edit description/tags found in the lefthand menu, scroll down to the Tags box and type it in. More information on states can be found at Bug States and information on tags can be found at Bug Tags

I am writing this about bugs filed when programs crash. When a new bug is filed, it has a default status of New.

If you cannot find anything that looks like the same bug then you can start the process of triage and fixing.

To find out what is causing the crash we need a crash report. Sometimes this will be attached to the bug but if not then we need to ask for one. The status will need to be changed to incomplete as it is missing information that is needed and the tag mt-needreport will need to be added.

When a crash report has been attached, it needs to be changed into a format that can be read by the person that fixes the bug. We call this the retrace. The tags should now be mt-needretrace and the status should still be Incomplete.

Once the retrace has been done you should have the information needed to find duplicates. You can search in Launchpad for duplicates or use BugHelper. You also now need to find a testcase which is used to see if the bug can be reproduced. The bugreporter needs to be asked for a step by step description of what they did when the crash happened. This is so other people can test if the bug happens to them when doing the same thing. The status should still be Incomplete and the tag should be mt-testcase.

When you have a good description of what to do, this needs to be followed to see if the problem can be reproduced. The tag mt-needtester is used to indicate that people are required to try and reproduce the bug.

If you can reproduce the bug and feel that the bug is ready to be fixed you use the tag mt-confirm to get a more skilled/experienced person to check that all the information needed is there and that the bug is ready to go forward. The status should still be Incomplete. The person who checks the bug will change the status to Confirmed if happy with the information or change the tag if anything is missing.

Now the bug status in Confirmed it can start the process of being fixed. This will either be done by ourselves or by Mozilla. When it is done by Mozilla, it is called upstream. Mozilla receive lots of bug reports so first we need to check that this bug hasn't been reported previously. If you cannot find the bug upstream then you use the tag mt-postupstream. This implies that it needs to be reported upstream and that the person volunteers to answer any questions that Mozilla has when trying to fix the bug.

When the bug is posted upstream the tag mt-confirm is used so that the bug can be checked upstream to see that it was submitted correctly and confirmed. Once this has been checked the status is changed to In Progress.

If a bug is fixed by us or if it is Ubuntu related, the tag should be mt-eval so that people know to work on it. These ones are ones for experienced programmers to look at.

When the evaluation is complete the tag mt-confirm is used so that the developer can verify that the bug can move on to the next stage. The status should be In Progress.

When a fix has been made for the bug the status changes to Fix Commited.

When a new version of the software is released with the bug fixed the status changes to Fix Released.

If a bug cannot be fixed or if the information required is not presented then the status is changed to Invalid. This is also the case if you do not get a response from the bug reporter.

Finding bugs to get started with

Some bugs are easier to deal with than others. Good bugs to start off with are ones that are tagged as mt-needtestcase and mt-needtester.

The Mozilla Team have a page which contains links to bugs in Firefox (FF) and Thunderbird (TB) for each different tag. This is found at Bug Tags. If you scroll down to the Needs Info section then you will find mt-needtestcase and mt-needtester with FF and TB to the right of them. These are links to the bugs for each program. Click on the link that interests you and then choose a bug to work on

CategoryMozillaTeam, CategoryBugSquad