Commit Access Policy: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(Replaced content with 'Moved to [http://www.mozilla.org/hacking/commit-access-policy/ http://www.mozilla.org/hacking/commit-access-policy/].')
 
Line 1: Line 1:
''v.1.0''
Moved to [http://www.mozilla.org/hacking/commit-access-policy/ http://www.mozilla.org/hacking/commit-access-policy/].
 
This document is the current 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.<br>Requirements: one voucher - any other user with level 2 or above access. Three areas - l10n, NSS, and NSPR - have their own requirements.<br><br>
# General access - all of SVN and Hg not in level 3. <br>Requirements: one voucher - any Mozilla code module owner.<br><br>
# Hg core product (Firefox/Thunderbird/Fennec) access.<br>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.
 
===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.
 
==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.)
 
==Level 3 - Core Product Access==
 
Requirements: http://www.mozilla.org/hacking/committer/ (Vouch: 2 module owners/peers, plus 1 super-reviewer)
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.
 
The repositories which fall in this category are:
 
CVS: /cvsroot (core product security releases are still made from here)
Hg:  mozilla-central
Hg:  comm-central
Hg:  releases/*
Hg:  mobile-browser
Hg:  tracemonkey
Hg:  projects/electrolysis
Hg:  projects/firefox-lorentz
Hg:  projects/nanojit-central

Latest revision as of 11:25, 30 March 2010

Moved to http://www.mozilla.org/hacking/commit-access-policy/.

Retrieved from "https://wiki.allizom.org/index.php?title=Commit_Access_Policy&oldid=211859"