BMO

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.

New Bots

If you have a bot that uses BMO, be sure to add it to the BMO/Bot Registry
so we know who to contact about it!

User Guide

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!

Road Map

We keep a yearly road map with our medium-term plans (1-2 years), at a high level. Also see our current projects for some of the big items we are working on in the current quarter.

Browser Support For BMO

Full Support includes: The current versions of Firefox, Chrome, Chromium, Safari, WebKit, and Edge; and the latest Firefox ESR.

Third-Party Applications

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.

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

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.

Updates are usually deployed on a weekly basis and are listed on the BMO/Recent Changes page.

Administrative Changes

If you need changes to BMO's configuration to support your team, project, etc., please consult this page before filing bugs:

BMO Development and Other Processes

Custom Bug Entry Forms

In the past, BMO developers supported writing custom bug entry forms specific for the needs of different projects and groups within Mozilla. In order to focus more on other important features, we will no longer be providing that support going forward. For more information on why this change was made, see here.

There is a new custom form framework being developed by an outside contributor named Sebastin Santy. It is still in the early stages but it eventually will be very useful for users who want to create a customized bug entry form that can be used to submit bugs to BMO.

Current Projects

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.

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.