BMO is a core piece of infrastructure at Mozilla. It is used to track not only bugs and feature requests but also many other tasks across various teams.
The BMO source is a slightly modified fork of Bugzilla with many custom extensions. It is currently based on Bugzilla 4.2 but with many features backported from 4.4 and master. All the BMO devs are also involved in the Bugzilla project, and we contribute features and fixes upstream where they are generally applicable, that is, not too specific to Mozilla's particular needs.
Updates are usually deployed on a weekly basis and are listed on the Recent Changes page.
- dkl: Dave Lawrence (Owner/Engineer)
- glob: Byron Jones (Owner/Engineer)
- dylan: Dylan Hardison (Engineer)
- mcote: Mark Côté (Manager)
- justdave: Dave Miller (Admin)
- gerv: Gervase Markham (Governator)
- lizzard: Liz Henry (Bugmaster)
Getting used to Bugzilla can be a bit daunting. We have a short introductory video available that is as gentle as possible. Also see the MDN article, What to do and what not to do in Bugzilla, which also contains instructions on getting elevated privileges.
We're putting together a user guide with helpful information on various aspects of Bugzilla. New and experienced users alike should benefit from it. There's a lot to go through, so please feel free to contribute!
Lots and lots of web apps and general tools have been written to interface with BMO. We have started cataloguing them. If you're looking for different ways to interface with BMO, check it out; similarly, if you are thinking about writing an app, check the catalogue to see if something similar exists that you could use, contribute to, or fork before setting out on your own.
There's one in particular that is particularly important: MozReview, Mozilla's new and growing code-review tool.
More Information about BMO
If you're building an application or tool that interfaces with BMO, you may be interested in the following:
- Best practices and etiquette for integrating external apps with BMO
- Info and plans on Bugzilla's REST API, and the older, deprecated BzAPI.
Looking for another way to access Bugzilla's raw data? Try the ElasticSearch cluster.
Contributing to BMO
If you'd like to help out with BMO specifically (as opposed to the general upstream Bugzilla project), you can find us in #bmo on irc.mozilla.org. If you plan on contributing patches, see the documentation on hacking BMO. You can file bugs under the bugzilla.mozilla.org product. Don't file them under the Bugzilla product unless you are sure it's a bug in the general Bugzilla product. In particular, all administrative changes should be filed under bugzilla.mozilla.org (see below for more).
Policies and Procedures
Code updates are normally deployed to bugzilla.mozilla.org late Monday/early Tuesday, US/Pacific time, at no specific time, if changes need to be pushed out. Security fixes or other fatal type errors will always go out as soon as possible.
If you need changes to BMO's configuration to support your team, project, etc., please consult these pages before filing bugs.
- General information on requesting Changes to BMO
- Adding a new product
- Adding a new "rapid release" version
- Adding a new BMO security group
- Retiring Products and Components: moving things to the Graveyard classification.
Other processes for BMO developers and admins:
This table lists the bugs representing the current quarterly goals (and, near the end of the quarter, sometimes next quarter's goals). Those that were set at the beginning of the quarter are tagged with the keyword "bmo-goal". The BMO team also regularly gets requests for high-priority work items throughout the quarter; those that will take more than a day or two in total, thus potentially jeopardizing other goals, are included below, tagged with "bmo-big". The daily smaller tasks are also generally tracked in Bugzilla but not represented in the table below.
P1 indicates a critical project. P2 indicates an important but deferrable item. P3 is as P2 but more deferrable. Note that all items are important, and it is presumed that lower-priority items will increase in priority over time as high-priority tasks are completed, i.e., we don't plan to defer any of these tasks indefinitely.
|1051056||--||The REST API needs to be versioned so that new changes can be made that do not break compatibility||RESOLVED||FIXED||David Lawrence [:dkl] (dkl)|
|1118365||P1||Write extension to use GitHub for Authentication||RESOLVED||FIXED||Dylan William Hardison [:dylan] (dylan)|
|1144468||P1||Bugzilla Auth Delegation via API Keys||ASSIGNED||Dylan William Hardison [:dylan] (dylan)|
|1144482||--||Migrate CI testing from Travis CI to Taskcluster||NEW||David Lawrence [:dkl] (dkl)|
|1144485||P1||Adapt upstream Selenium test suite to BMO||NEW||David Lawrence [:dkl] (dkl)|
|1150541||--||[tracking] feature parity between classic show-bug and the bug-modal view||NEW||Byron Jones ‹:glob› (glob)|
6 Total; 4 Open (66.67%); 2 Resolved (33.33%); 0 Verified (0%);
|44393||P2||develop an extension that provides comment-only inbound email support||ASSIGNED||Byron Jones ‹:glob› (glob)|
|956390||P3||Add suggested reviewers capability to the ui review flag||ASSIGNED||David Lawrence [:dkl] (dkl)|
2 Total; 2 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Further documentation about goals above and other projects follows:
- User Roles
- Generate different user roles based on what tasks a user is trying to complete when using the BMO system.
Some of these will have on-going maintenance and improvements, but the initial deployment has been accomplished. Others have been abandoned or rejected due to various factors, noted below.
- Change Notification System
- 4.0 Upgrade
- 4.2 Upgrade (Completed March 5th, 2013)
- User Profiles
- Tracking Flags
- Native REST API
- Pulse Integration
- This was completed and deployed, but it generated a lot of traffic and is of questionable utility since it must access Bugzilla as an anonymous user. A simpler, more general system is the Change Notification System.
- Migrating Bugzilla and BMO code from bzr to git
- Completed 2014/03/11.