Incubator Repositories Proposal

June 6th, 2008

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 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:

  1. 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
  2. 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.

  1. Make sure the creation of the Incubator Repository to which you wish access has been approved.
  2. File a bug. Product:; 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 <> “). 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.
  3. Each of the two sponsors should comment in the bug saying s/he’s sponsoring the Incubator Repository and your participation in it.
  4. 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.
  5. Complete the Contribution Form and fax it to the location specified on the Form.
  6. Update the bug to note that you’ve faxed in the Form.
  7. An appropriate Mozilla representative will update the bug to say whether s/he has received the faxed Form.
  8. 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.
  9. The Mozilla representative will double-check that the needed info is recorded and, if so, create an account.
  10. The Mozilla representative will then reassign the bug to IT to have your SSH public key added.
  11. A Mozilla IT representative will update the bug with account creation information and close the bug.

4 comments for “Incubator Repositories Proposal”

  1. 1

    Donnie Berkholz said on June 6th, 2008 at 1:30 pm:

    This seems like a whole lot of work to basically duplicate something that’s trivial with a DVCS.

  2. 2

    Ray Kiddy said on June 8th, 2008 at 5:07 pm:

    I had hoped this would address the difficulty of submitting patches to test code. Right now, the same policy guides access to the tests and the source, which does not make sense if you want to encourage more people to write tests. This seems more oriented to provided repository access to people doing research projects, which Mozilla always handled.

    If MoCo wants to encourage people to check in test code (perhaps as a way to get credibility to later get code access, for example), then 11 steps seems like a lot of steps.

  3. 3

    Mitchell Baker said on June 8th, 2008 at 10:45 pm:

    Donnie: I’m not sure if you mean the setting up of a repository is trivial. If so, no argument there. This is meant to address the policy question of who has access to commit code to it. It’s also easy to set up a private repository for people who want to work together, we don’t need policy for that.

    Ray, you’re right, this isn’t aimed at test code. You do raise a good point; maybe we should have a way for people to get access to commit test code that doesn’t involve the level of review required for commit access to the code we ship as a product.

  4. 4

    Chris W said on June 16th, 2008 at 8:45 am:

    Actually Donnie, IIRC, at least for Moz2 development (as necessitated by the massive, included automated, reworkings & mergings) Mozilla uses the Mercurial DVCS.
    I think the point of the central repositories in this policy is the ability to give visibility to all of (merited) large change-sets by devs new to Mozilla (and so who aren’t yet authorized under the quality policy for it to be added as a branch). This does mean a new code review & committer approval process, additional to & paralleling that for the submission of patches.

    I can’t imagine anyone submitting a test suite that big, so these 11 steps aren’t applicable to those. I was glad to read Ray’s worthy suggestion that coding tests can be a good beginning towards qualifying as a MozDev with commit privileges. Isn’t the corollary then that the review process should be pretty similar? While tests have to be sufficient rather than optimal, there is still the opportunity to learn from another’s experience, which should be seized if they can take the time to give feedback. While such feedback (hopefully!) may involve more characters, including “[not] yet”, that doesn’t mean it outweighs the “thanks for this contribution” sentiment. Our practical learning zone necessarily starts beyond the comfort zone of what we can already do, but we can take small steps if proactive. Of course, great if there’s true potential for process streamlining (that justifies the review process to sanction it ;).

Skip past the sidebar