Education/Collaboration/Bugzilla
Contents
Bugzilla
Mozilla is the creator of one of the most popular issue tracking systems in the world--bugzilla. Many open source projects use bugzilla to keep track of bugs, enhancement requests, and otherwise keep a historical record of a project's development. Mozilla is no different, using its own instance of bugzilla.
Anyone can create a Mozilla bugzilla account and file new bugs. You can (and should) create a Mozilla bugzilla account so that you can participate in bugs, and follow development activity. Modifying some aspects of a bug requires increased rights.
Common Tasks
Write a new bug report
The Bug Writing Guidelines will help you file bugs that get attention, but don't forget to check for duplicates first.
Get an existing bug report assigned to you
As a new bugzilla user you won't have the privileges necessary to assign a bug to yourself. You don't need to be assigned to a bug to work on it or submit patches, but having it assigned to you is a way of letting the community know what you are doing. The easiest way to get a bug assigned is to join #Education and ask for the help of someone who has privileges.
Comment on a bug
Anyone can comment on a bug, but keep it to the point and keep it technical. Please read the bugzilla etiquette page for guidance. The basic rule: a comment should move the bug closer to being resolved.
Submit a patch
Just click 'Add an attachment'. Typically, you are adding a text file containing a 'diff' of changes you have made to the source code. (See Creating a Patch for more info.) When submitting further patches you can mark previous patches as no longer valid.
Follow a bug
If you file a bug report, each new comment or change in the bug is emailed to you. You can also add yourself to the list of people who receive emails about a bug by clicking Submit at the bottom of the page (whether or not you actually make a comment).
Watch a user
Adding a "Watch" for a bugzilla user is similar to following a bug, but will mean that you get sent copies of all bugmail for the specified user. Be careful who you choose, as some users get a lot of bugmail! To set a watch, do the following:
- On the main Mozilla bugzilla page, click Preferences (you'll need to be logged in)
- Select the Email Preferences tab
- Scroll to the bottom under User Watching and add the bugmail address for the user you wish to watch
Ask for a review
If you have submitted a patch that is ready to be added to the source code, set the 'Review' drop down to '?' when you submit the patch. You will be prompted for the name of the person you wish to review your code. Finding the right person for a review can be tricky, but certain people are known to look after certain parts of the source code. Ask in #Education for help finding the right person.
Culture and Etiquette
From bugzilla etiquette:
- No pointless comments. Unless you have something constructive and helpful to say, do not add a comment to a bug. In bugs where there is a heated debate going on, you should be even more inclined not to add a comment. Unless you have something new to contribute, then the bug owner is aware of all the issues, and will make a judgement as to what to do. If you agree the bug should be fixed, vote for it. Additional "I see this too" or "It works for me" comments are unnecessary unless they are on a different platform or a significantly different build. Constructive and helpful thoughts unrelated to the topic of the bug should go in the appropriate newsgroup.
IRC, mailing lists, blogs, etc. are all useful for keeping people informed about your work; but the best way to get access to the right people is through bugzilla. Every developer working on Mozilla uses it, and a properly filed bug (e.g., in the correct product, component, etc.) will insure it gets seen.
Not all work belongs in bugzilla. Extensions, experiments with existing technologies, the creation of new tools, etc. are probably not appropriate for bugzilla. Knowing the line between what does and doesn't belong takes time, and you can always ask in the #education channel.
Learning to use bugzilla properly can take time (many aspects of the classification system, or use of flags are cryptic even to the experienced). Not being 100% sure how to proceed shouldn't stop you from trying, remembering that you can always ask for help in the #education channel. Here is some information about the process of getting work reviewed and "landed in the tree" (i.e., committed to the hg repository).
Finally, be prepared for no-nonsense, highly technical, sometimes critical environment in bugzilla. Remember that this is where technical decisions about what gets accepted/rejected in terms of code are made. Personal attacks are highly inappropriate, but be prepared to defend the technical merits of your patches from sometimes merciless criticism.
Good first bugs
One of the goals of Mozilla Education is to provide an up-to-date list of potential projects for students, in the form of bugs in bugzilla. You can see a list of such bugs here:
Here is the list of bugs with the "student-project" keyword:
