Stuart recently described the need to allow improved collaboration with groups of people in specific circumstances: changes to Mozilla code that are larger (and possibly more experimental) than individual patches and where the new contributors don’t yet have commit access to the source tree and where existing Mozilla contributors want that collaboration to occur within a Mozilla-hosted source repository.
At the same time, our policies for determining who has commit access are critical to maintaining the quality of our work; we certainly don’t want to change that.
We (Brendan, Stuart and I) have come up with a proposal that we think gives us some flexibility without changing the rules for obtaining commit access to mozilla-central. It includes a mechanism for allowing such collaboration plus a description of the logistics such as how to file a bug for individual access and get it closed. Comments are welcome here or in the mozilla.org Governance newsgroup. (You can also participate through the mozilla.governance Google Group. )
Incubator Repositories
Incubator Repositories are a tool available to module owners in the following circumstances:
- the module owners are engaged in significant cooperative development with contributors who are not yet experienced enough with Mozilla to have commit access to the Mozilla source tree; and
- it is impractical to break contributions into bug-sized patches and follow the standard review and check-in process, either because the scope of work makes this difficult, or the work is experimental and a precursor to patches that will eventually end up in Mozilla-central or another reason the module owners can describe persuasively.
In other words, an Incubator Repository is a temporary repository hosted by Mozilla where we allow people to check code in before they have official source code write access for our production code base. An Incubator Repository is not needed for repositories where all contributors have full source code commit access.
An Incubator Repository should meet the following conditions:
- An incubator repository requires 2 module owners to be committed as sponsors.
- The work is important to Mozilla’s stated development roadmap; Incubator Repositories are not a hosting site for potentially-related work.
- The work is not duplicative of work in mozilla-central. There is some possibility that duplicative incubator repositories are possible, we can look at that if the setting arises.
- Incubator branches are temporary. In general, an incubator branch probably shouldn’t last longer than six months. By that time it should be clear whether the work has potential. And if it is an effective branch, there should be enough activity from the contributors to determine which if any of them are ready for commit access. However, setting a one-size-fits-all date for all which must be tracked for its own sake requires a bureaucracy to track and manage that. Instead, we’ll say that six months is the general timeframe. For a branch to last longer, the sponsors should have a good rationale why this is the case, they should ideally make that rationale to the Incubator Repositories module owner, and they must make that case effectively if the Incubator Repositories module owner or peers ask.
- Incubator Repositories are publicly available repositories just like mozilla-central.
- Incubator Repositories incubate both code and people. They are not training branches where the code doesn’t matter. They are not intended to provide examples of coding to evaluate someone’s readiness for commit access; we have policies for that. They are intended to help the sponsors make progress that otherwise wouldn’t be possible while new contributors learn about Mozilla and become known to Mozilla.
- Participants in an Incubator Repository may also develop patches that relate to the work in mozilla-central, for example a patch relating to start-up performance. When this happens, the patch or patches in question should be submitted through the standard process. This not only improves our code, but it provides a chance for the author’s work to become known, which is necessary for commit-access outside the Incubator Repository. The sponsors are responsible for encouraging this process.
- There is no right of potential contributors to have an incubator repository because it is easier for them. There is the ability of existing module owners to sponsor one.
- The sponsors are responsible for the operation of the Incubator Repository.
Logistics and Operational Parameters
- The creation of an Incubator Repository must be approved by the owner (or a designated peer) of the Incubator Repository module. (This is a new module which we will create as part of the implementation of this policy assuming it is approved.)
- The proposal should describe why the Incubator Repository meets the required conditions, who the sponsors are, hoped-for results of the Incubator Repository, the approximate number of people likely to be given check-in access through this process, and any possible effects on other parts of Mozilla.
- The proposal should also be filed as a bug and also posted in the relevant newsgroup.
- The sponsors are responsible for figuring out a reasonable system for getting code from the Incubator Repository into mozilla-central. “Reasonable” generally does not mean dropping six months of work on reviewers and asking for code review. Sponsors may meet this responsibility by using Mozilla code-review techniques in the Incubator Repository or by other means, but they are responsible for getting code review in reasonable increments.
- Anyone checking into an Incubator Repository must have signed a CVS Contributor Form on file with the Mozilla Foundation.
- Once approval for an Incubator Repository has been granted and recorded in the appropriate bug, the sponsor or Incubator participants should file a bug asking for commit access for that person for the Incubator Repository. Details on filing the bug and getting it closed are below.
Incubator Commit Access
Here’s a list of the steps that need to happen to get Incubator Commit Access.
- Make sure the creation of the Incubator Repository to which you wish access has been approved.
- File a bug. Product: mozilla.org; Component: CVS AccountRequest. Don’t change the Default Assignee or the Default QA Contact. Your summary should say something about creating an Incubator Account (“Incubator Account Request – John Doe <jdoe@example.com> “). You should also include in the bug a pointer to the earlier bug in which the creation of the Incubator Repository in question was approved.
- Each of the two sponsors should comment in the bug saying s/he’s sponsoring the Incubator Repository and your participation in it.
- Make sure to include your CVS SSH public key as an attachment to the bug. (Please mark it as text/plain when attaching it!) Note that you will need to attach an SSH key for all types of access.
- Complete the Contribution Form and fax it to the location specified on the Form.
- Update the bug to note that you’ve faxed in the Form.
- An appropriate Mozilla representative will update the bug to say whether s/he has received the faxed Form.
- Update the bug when all the needed info is in the bug. This way, Bugzilla can send off mail to the Mozilla representative tending to accounts.
- The Mozilla representative will double-check that the needed info is recorded and, if so, create an account.
- The Mozilla representative will then reassign the bug to IT to have your SSH public key added.
- A Mozilla IT representative will update the bug with account creation information and close the bug.