Commit Access Policy
v.0.3
|
THIS PAGE IS A WORKING DRAFT | 
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
This document is a proposal for a unified and simple policy for gaining access to commit to Mozilla source code repositories.
Rationale
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.
Summary
3 levels, in order of increasing access:
- Try/User/Incubator access - try servers, user partitions and incubator repositories in Hg.
Requirements: one voucher - any other user with level 2 or above access. Three areas - l10n, NSS, and NSPR - have their own requirements. - General access - all of SVN and Hg not in level 3.
Requirements: one voucher - any Mozilla code module owner. - Hg core product (Firefox/Thunderbird/Fennec) access.
Requirements: two vouchers and approval from a super-reviewer.
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: one voucher - any another user with level 2 or above access
This is the lowest level of access. It allows someone to check in to the try trees (try and try-comm-central), the user trees and the incubator 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".
Incubators are in this group because they were set up as a mechanism to allow people in exactly that target audience to work with us.
[Technical: hg_mozilla permissions bit only.]
Level 1a - Named Voucher
Requirements: one voucher - the module owner or a peer responsible for that tree
This 'mezzanine' level applies to NSPR, NSS and l10n.
NSPR and NSS have historically wished to maintain very close control on who can check in. These trees are outside the general level system. A specific OK from the owner of those trees is required to be granted access there. Currently, this code is still developed in CVS.
In the case of l10n, we have it as 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 tree access implies level 1 access but not level 2 access.
[Technical: l10n committers get the hg_l10n permissions bit but not hg_other_src (see below).]
Level 2 - General Access
Requirements: one voucher - any Mozilla code module owner
This access allows one to check in to most places other than core product code, and the exceptions listed above. That means all of SVN and much of Hg. The existing per-tree technical controls in SVN are abolished, to be replaced by social controls.
[Technical: This would require a new Hg permissions bit, tentatively called hg_other_src, but we might do some renaming at the same time. All existing non-l10n committers would be grandfathered in with this bit, and all non-l10n non-core trees changed to require it.]
Level 3 - Core Product Access
Requirements: http://www.mozilla.org/hacking/committer/ (Vouch: 2 module owners/peers, plus 1 SR who has not reviewed their patches)
This permission gives access to check into any tree from which executable code becomes part of our core products - Firefox, Fennec 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.
This is a codified form of a point from the above-referenced document: "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 [to gain commit access]."
People with this access may not actually be working on Firefox, Fennec or Thunderbird, but their ability to affect them means that the level of trust and familarity required for access are higher.
A probably-inaccurate list of repositories which would fall in this category:
CVS: /cvsroot (core product security releases are still made from here) Hg: mozilla-central Hg: comm-central Hg: releases/* Hg: mobile-browser Hg: tracemonkey
[Technical: In Hg, this would equate to being given the hg_mozsrc permissions bit, and all the trees covered would require that bit to check in.]
Open Issues
- CVS does not easily allow fine-grained control, and so there are people with CVS commit access who have not gone through the level 3 process. Social controls are currently being used here.
- The xforms tree currently requires hg_mozsrc. This seems unnecessary, as it's pretty clear we aren't going to ship the code. We should relax that.