Mozilla Commit Access Policy

v.1.1

This document states what permissions you need when following the procedure to gain access to commit to various Mozilla source code repositories.

Rationale

There are two sorts of control which can be used to stop people checking in - technical and social.

1. A "full technical" implementation would have per-directory permissions everywhere, but would lead to a greatly-increased management overhead for IT, vouchers and developers alike.
2. A "full social" implementation would just have a single permission which gave you complete access to everything, but (depending on the height of the barrier to that permission) there is a risk of making developer's lives more difficult when they are excluded, or of giving the untrustworthy or incompetent power to mess things up.

Therefore, a good policy balances the use of technical and social controls to minimize both management overhead and risk to the development process.

Summary

3 levels, in order of increasing access:

1. Try/User access - ‘try’ trees and user repositories in Hg, plus any other tree placed at this level.

   Requirements: one voucher - any other user with level 2 or above access.

2. General access - all of Hg not in level 3 or listed as an exception. Currently, this level is rarely used for Mozilla development.

   Requirements: one voucher - any current Mozilla code module owner.

3. Hg core product (Firefox/Thunderbird/GeckoView) access.

   Requirements: two vouchers - current module owners or peers of code stored in a repo at this level.

Each level of permission implies having the previous levels - e.g. level 2 implies level 1. A module owner creating a new tree can decide at what level that tree should live, depending on the trade-off they want to make between control and ease of access.

Level 1 - Try/User/Incubator Access

Requirements: Contributors require one voucher - any other user with level 2 or above access. Mozilla employees do not require vouching.

This is the lowest level of access. It allows someone to check in to the try trees (try and try-comm-central) and the user trees. Because this is all it gives, this sort of access can be given out generously to anyone who would find it convenient when helping us or working on a developer's personal project, without worrying about them affecting core code. In other words, the target audience for this sort of access might be defined as "friends of and collaborators with Mozilla".

Level 1a - Named Voucher

Requirements: one voucher - the module owner or a peer responsible for that tree

Some trees, most often those from which code is pushed automatically into use on major Mozilla websites, requires special permission for checkin access. You need permission from the listed owner in order to get access to check in to their tree. The trees and owners are:

Hg

L10n

In addition, l10n is a separate category so l10n-only access can be more freely given than might be the case if it were included in level 2. This exception is worth making because of the size and diversity of the l10n community and the looser relationship people in it sometimes have to the rest of the project. l10n access implies level 1 access but not level 2 access. The named vouchers are the owner and peers of the Localization module.

Level 2 - General Access

Requirements: one voucher - any current Mozilla code module owner

This access allows one to check in to everywhere in any SCM (Hg or Git) except the core product code in Hg and the exceptions listed above.

Level 3 - Core Product Access

Requirements: two vouchers - current module owners or peers of code stored at this level, or owners or peers of the "Tree Sheriffs" module

Someone can be upgraded from level 2 to level 3 by being vouched for by a single current module owner of level-3-stored code.

This permission gives access to check into any tree from which executable code becomes part of our core products - Firefox, GeckoView and Thunderbird. This is fundamentally a statement of trust in and familiarity with an individual, and so access to one such tree gives access to all such trees, although social controls may prevent people checking in to certain ones.

People with this access may not actually be working on Firefox, GeckoView or Thunderbird, but their ability to affect them means that the level of trust and familarity required for access are higher.

With this level (scm_level_3), the developer can use Lando to land code.

The repositories which fall in this category are:

Hg

autoland
mozilla-central
comm-central

...plus any other repo from which code is merged to any of the above without a thorough review at merge time.