|
|
| (7 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| ''v.0.2''
| | Moved to [http://www.mozilla.org/hacking/commit-access-policy/ http://www.mozilla.org/hacking/commit-access-policy/]. |
| | |
| {{Draft}}
| |
| | |
| Currently, Mozilla has a large number of code trees in various source code management systems, many of which have differing requirements for access. This is confusing and difficult for both developers and administrators. This document is the first draft of a vision for what a unified commit access policy might look like. Having a clear commit access policy makes the lives of developers and administrators alike easier.
| |
| | |
| This document divides our repositories into categories, with each category having a different procedure. The aim has been to minimize the number of categories (the proposal has 3), and therefore procedures. A secondary aim is also to not have to change too much from where we are today; my understanding is that most repositories also work in a manner fairly close to one of the suggested categories. Reed's [[Commit_Policy:Current_Procedures|current procedures list]] was an important source document for this policy. However, this document still may well contain factual inaccuracies or unworkable suggestions. Proceed with caution.
| |
| | |
| 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><br>Requirements: one voucher, who is any other user with level 2 or above Hg access.<br><br>
| |
| # Access to a single SVN tree, Hg l10n, NSS, NSPR, or "all the other Hg trees".<br><br>Requirements: one voucher from the list of people responsible for that particular tree or group of trees. (A list would be kept.)<br><br>
| |
| # Hg core product (Firefox/Thunderbird/Fennec) access.<br><br>Requirements: two vouchers and approval from a super-reviewer.<br><br>
| |
| | |
| In the case of Hg, each level of permission implies having the previous levels - e.g. level 2 implies level 1.
| |
| | |
| Note: The rules surrounding Level 3 permission are basically what has already been agreed for the product repositories.
| |
| | |
| ==Try/User/Incubator Access==
| |
| | |
| Requirements: one voucher, who is another Hg user (level 2 or above)
| |
| | |
| 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. However, it is socially expected that the person responsible for an incubator tree would be the person vouching for access for other collaborators.
| |
| | |
| So social controls would be used to prevent someone checking in to e.g. the foo incubator when the person who vouched for them did so because he wanted their help in his personal user tree "bar".
| |
| | |
| ''[Technical: hg_mozilla permissions bit only.]''
| |
| | |
| ==Named Voucher==
| |
| | |
| Requirements: one voucher from list responsible for that tree or group of trees
| |
|
| |
| This access allows one to check in to places other than core product code. In Hg, one vouch would give access to check in everywhere else except l10n; in SVN, access is generally given on a per-tree basis because the permissions system permits that easily. This "named voucher" policy is also used for the NSS and NSPR partitions in CVS.
| |
| | |
| Some SVN trees currently require two named vouchers; I think that, in practice, this does not provide any extra benefit. It seems unlikely that if one potential voucher said "I know this guy, and I want him to help", another one would refuse. And if they would, you probably wouldn't want to have that discussion in an access request bug anyway. So I would recommend harmonizing all tree access to one voucher.
| |
| | |
| A public list would be kept mapping repositories to the person or persons permitted to vouch for access to that repository. Here is an example (i.e. not a proposal, and certainly partial) of such a list:
| |
| | |
| CVS/NSPR: Wan-Teh Chang, Nelson Bolyard
| |
| CVS/NSS: Bob Relyea, Nelson Bolyard, Julien Pierre
| |
| SVN/mozillamessaging.com: David Ascher
| |
| SVN/<website localization tree>: Axel Hecht, Seth Bindernagel
| |
| Hg/l10n: Axel Hecht, Seth Bindernagel
| |
| Hg/"all other trees": Any Mozilla module owner
| |
| ...
| |
| | |
| ''[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.]''
| |
| | |
| ===L10n Access===
| |
| | |
| Requirements: vouch by Axel or his delegate
| |
|
| |
| This is a special case for Hg, which it 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.
| |
| | |
| In CVS, l10n committers were restricted to their own tree. In Hg, they can currently check in to everywhere else non-core as well. We are fixing that by the introduction of the hg_other_src permissions bit above, which l10n committers would not have. So then, Hg l10n committers would be restricted just to the l10n tree(s). The hope is to allow more l10n contributors to be given commit access sooner, because the risk is lower, and thereby make their lives easier.
| |
| | |
| ''[Technical: l10n committers get the hg_l10n permissions bit.]''
| |
| | |
| ====Open Issues====
| |
| | |
| # Do we need finer-grained controls on the Hg "all other trees" permission, or can we rely as now on social controls?
| |
| | |
| ==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 - or to trees from which code might be merged to those trees without comprehensive review '''at merge time'''. 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]."
| |
| | |
| Note that above I say "executable code" on purpose: it should be possible to contribute fully to l10n without this level of access. (If l10n checkins can break the main trees, we need to fix our systems. :-)
| |
| | |
| 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 this process. Social controls are currently being used here. This problem will go away as Firefox 3.0 falls out of support at the end of December 2009.
| |
| # Some of the Hg trees listed may not be locked down with hg_mozsrc. If they were, that might lock out some people, and we'd need to decide whether to grandfather them in.
| |
| # The xforms tree currently requires hg_mozsrc. This seems unnecessary, as it's pretty clear we aren't going to ship the code.
| |