Skip to main content

Becoming A Mozilla Committer

Mozilla has a number of source code repositories. This document outlines the requirements for earning commit access to the following repositories:

  • mozilla-central Hg repository
  • comm-central Hg repository
  • Mozilla's main CVS repository.

There are separate requirements for creating and gaining commit access to an incubator repository

A list of Mozilla's many repositories and their requirements is available in wiki form. In the future we may review the policies of other repositories, and/or develop a baseline for communicating or determining how access is granted.

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 to the mozilla-central, comm-central or CVS repository. This process applies to everyone who wants write-access to these repositories. Employment with any particular entity (including the Mozilla Foundation) does not change the need to comply with this policy. 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 send it to us.
  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.

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 not have previously reviewed or super-reviewed your patches. The goal of this requirement is to prevent over-optimism or "group-think" by a set of people who have been working closely together. We do this by requiring the super-reviewer to have a fresh perspective.

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, Calendar 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. In the future we may reevaluate 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, bugzilla -- have developed their own rules for source code commit access. It's possible that at some point we'll look at whether there should be some project-wide requirements. For example, we might decide that each repository should publicly explain its criteria for access, or that there is some baseline process. For now those projects should continue as they have been, except for the Calendar project. Historically the Calendar project has not required super-review for check-in of code, and so has not need a super-reviewer approval to gain commit access. However, the Calendar project and Thunderbird are closely related, the committers share the comm-central repository and recent discussions (in the mozilla governance newsgroup) have indicated it would be helpful for the Calendar committers to be vetted for access for the entire comm-central repository and to be treated like committers to the Thunderbird-centric areas of this repository. As of June 2009, super-reviewer approval will be required for commit access to the Calendar project as well.

Revoking Commit Access

If someone consistently causes difficulties with these source repositories due to poor behavior or other serious problems then commit access may be revoked. We have no precise process for this as it has been a rare or nonexistent problem to date. The process for this is for one or more committers with concerns to notify the owner of the Commit Access Policy sub-module if you have clear examples of someone whom you believe has reached this level of problem. Do not do so carelessly, or based on passing irritation or without a sense that you are not alone in your concerns. The Commit Access Policy owner will investigate or cause an investigation to occur, privately at first and perhaps completely privately.

Dormant Accounts

As of June 2009 we're working on a plan for addressing accounts that have seen no activity for some specified period of time. We may disable such accounts. Assuming we do this, the process for reactivating them will be a much more lightweight process than that for obtaining commit access the first time.

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