Mozilla Commit Access Policy
This document states what permissions you need when following the procedure to gain access to commit to various Mozilla source code repositories.
There are two sorts of control which can be used to stop people checking in - technical and social.
- 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.
- 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.
3 levels, in order of increasing access:
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.
General access - all of Hg not in level 3 or listed as an exception.
Requirements: one voucher - any Mozilla code module owner.
Hg core product (Firefox/Thunderbird/GeckoView) access.
Requirements: two vouchers - 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-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:
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 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 - 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 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, Firefox for Android and Thunderbird. To put it another way, the unifying factor is that it should not be possible to break core product tinderboxes unless you have this access. 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. (Peers can vouch because the number of modules at this level is smaller, and because if you are working only in a single area of the code, there may not be multiple module owners familiar with your work.)
People with this access may not actually be working on Firefox, Firefox for Android or Thunderbird, but their ability to affect them means that the level of trust and familarity required for access are higher.
The repositories which fall in this category are:
autoland mozilla-central comm-central releases/*
...plus any other repo from which code is merged to any of the above without a thorough review at merge time.