Skip to main content

Becoming A Mozilla Committer

This document describes steps required to become a Mozilla committer. This document applies to all potential contributors.

Note: we recently (June 2008) updated the Committer's Agreement form. There's a FAQ about the changes.

Stop!

Have you written enough patches for Mozilla so that the patch reviewers have a good feel for your work and so that it's clear you understand the review process? If you haven't, you'll want to do that -- people will want a feel for you and your code before vouching for you. If you have, read on...

Logistics

For those in a hurry, here's a list of the steps that need to happen to become a Mozilla committer. A description and rationale for the process follows this section.

  1. File a bug in the appropriate "Account Request" component.
  2. When you have a voucher, ask that person to add a comment to the bug saying s/he's vouching.
  3. When you have a second voucher, ask that person to add a comment to the bug saying s/he's vouching.
  4. Determine whether or not you need a super-reviewer approval, as discussed below.
  5. If not, note in the bug why super-reviewer approval is not needed.
  6. If so, ask the relevant super-reviewer to note in the bug when he or she gives approval.
  7. Make sure to include your SSH public key as an attachment to the bug. (Please mark it as text/plain when attaching it!) Note that you will need to attach an SSH key for all types of access.
  8. Complete the Committer's Agreement (both sections 1 and 6), and mail it to the location specified. You can also fax it for faster service.
  9. Update the bug to note that you've sent in the Agreement.
  10. An appropriate Mozilla representative will update the bug to say whether s/he has received the Agreement.
  11. Update the bug when all the needed info is in the bug. This way, Bugzilla can send off mail to the Mozilla representative tending to account creation.
  12. The Mozilla representative will double-check that the needed info is recorded and, if so, create an account.
  13. The Mozilla representative will then reassign the bug to IT to have your SSH public key added.
  14. A Mozilla IT representative will update the bug with account creation information and close the bug.

General

To get commit access to Mozilla source code you basically need to demonstrate that you know what you're doing. You'll need to demonstrate competence with the code you're working with, other Mozilla code you might affect with your work, Mozilla check-in, build and related processes (like watching the builds after you've checked in code to make sure you haven't broken something) and basic good coding practices. It also helps if you can leap tall buildings in a single bound. You'll need to demonstrate this to a set of people who are willing to be associated with your check-ins. We judge this by peer review, code review, and our special X-ray vision.

In all cases, you need to demonstrate you know what's going on, find a set of people who have adequate authority and will vouch for your competence, and complete and sign a Committer's Agreement. You'll start the process of getting access by submitting good patches and having them reviewed by the module owner and other appropriate people. When you think you have submitted patches that demonstrate the criteria above, you can begin following the directions for obtaining commit access to the source tree.

This process applies to everyone who wants write-access to the Mozilla source repository. Employment with any particular entity (including the Mozilla Foundation) does not change the need to comply with this policy.

General Rule

The General Rule for getting commit access to a Mozilla source tree is:

  1. Two vouchers and one super-reviewer must approve your request in writing (through Bugzilla).
  2. The super-reviewer must be from outside the modules in which you have been working.
  3. One of the 3 people approving your access must not be employed by the same entity as you.

Vouchers Approvals

You need two vouchers. Each voucher should be the owner or a peer of a module or modules to which you've been submitting patches. Each voucher must already have commit access and be confident enough in you to be associated with your check-ins. Your vouchers are responsible for your bustages in the unfortunate event that you break the tree and leave. They are responsible for making sure you know and follow the rules in general, act promptly to fix regressions, are aware of and respect tree closures, etc. The vouchers' responsibility extends for three months after you are granted source code commit access. If you've lived in the tree without significant issues for three months, we assume you're ready to stand on your own. If somehow there are persistent problems during the first three months, the vouchers have the authority to request revocation of your access during this period. Vouching is a big responsibility, so people will make this commitment only after due consideration. A voucher who helps people who aren't prepared get access to the source tree will find that his or her own credibility suffers as well.

Super-Reviewer Approval

If your code is in one or more modules that are included in Firefox, Thunderbird, or the SeaMonkey suite, then you also need the approval of a "super-reviewer." Super-reviewers are a small set of contributors who have -- and are known to have -- a wide-angle view of the codebase, and are particularly acute at identifying cross-module issues, integration issues, and other issues beyond the ability of the patch to resolve the specified issue. More information on super-review and a list of super-reviewers can be found at http://www.mozilla.org/hacking/reviewers.html.

Scope of Review for Approval

A nominee should have demonstrated both technical chops and an understanding of Mozilla workstyle (awareness of tree closures, regressions and bustage processes, good citizenship, good responsiveness to code reviews, makes changes when appropriate, etc.).

A nominee's code ought demonstrate that s/he has encountered complex topics and handled them well. It is probably not enough to demonstrate code that does nothing inappropriate.

Currently, it seems unlikely that this would be demonstrated in less than 3 or 4 good-sized patches. This process takes a while, so a new participant should anticipate a period during which the response is "could well be approved, but I don't have enough info yet." Keep producing good patches and this period will pass.

Here are examples of the types of things the vouchers and super-reviewers will look for.

  • Code Quality
    • Does the proposed committer's code solve the problem it was intended to? does it do so well? does the code solve an underlying problem rather than fix a symptom?
    • Understanding of relevant aspects of Mozilla architecture; the definition of "relevant" will depend on the area(s) in which one works.
    • Understanding when one's code affects other modules and needs input beyond one's own area of expertise
  • Work Style
    • Understands and respects tree rules and related processes
    • Availability to deal with issues in one's check-ins
    • Addresses review comments responsibly
  • Experience
    • Should be a set of good-sized patches adequate to judge quality issues; and
    • Should have a track record that demonstrates other criteria -- at least a couple of months of active hacking that meets the other criteria

Exceptions to Super-Reviewer Requirement

Historically, the requirement for super-review has had some exceptions. As of April 2007, we are evaluating whether changes to these exceptions make sense. For now, the exceptions listed below remain, and the module owners of these groups determine the requirement for commit access to these modules.

  • NSS
  • NSPR
  • JavaScript
  • Build

Modules not associated with Firefox, Thunderbird, or SeaMonkey

Historically, code which is not part of the browser and mail products -- e.g., webtools, the source tree for the website, etc. -- have developed their own rules for source code commit access. As of April 2007, we are evaluating whether this makes sense or whether one policy should address all Mozilla code. For now those projects should continue as they have been.

Contributor Form

You'll also need to fill out and submit the Committer's Agreement (both sections 1 and 6) to get your account set up. Read it carefully - signing it indicates you understand and agree to our legal requirements. Breaking these rules could cause legal problems for Mozilla and may cause us to revoke your access. If you have any questions, ask us.

Problems With Your Account