You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

Getting CVS Write Access to Mozilla

This document describes steps required to obtain CVS write access. This document applies to all potential contributors.

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 get Commit Access. A description and rationale for the process follows the Logistics section.

  1. File a bug (naturally). Product: mozilla.org ; Component: CVS Account Request. Don't change the Default Assignee or the Default QA Contact. It would be helpful if your summary says something about creating a CVS account ("CVS Account Request - John Doe <jdoe@example.com>").
  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 CVS 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 Contribution Form and fax it to the location specified on the Form.
  9. Update the bug to note that you've faxed in the Form.
  10. An appropriate Mozilla representative will update the bug to say whether s/he has received the faxed Form.
  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 CVS accounts.
  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 CVS Contributor Form. You'll start the process of getting CVS 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 write access to the 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 CVS 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 CVS Contributor Form to get your account set up. Signing the form 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.

  • Some restrictions still apply to contributions of crypto source code and interfaces to crypto applications. Please consult with folks in the mozilla.dev.tech.crypto newsgroup before you prepare to check-in anything new. (See the Mozilla Crypto FAQ for background information on Mozilla and crypto support.)
  • All new source files must contain a license header using the MPL/LGPL/GPL tri-license or another license approved by mozilla.org (see the licensing policy); you must provide any legal notices required by the license.
  • The code you check-in must belong to you or you must have full rights to publish and license it.
  • Your CVS account is for your own use only. Do not let others use it. If you check-in someone else's patch, attribute the patch to them in the CVS commit log.

Problems With Your Account

Contact: Marcia Knous