Summary

In Q1 of 2015, the DeveloperServices team investigated if Mozilla could benefit by operating a Github Enterprise (GHE) instance. This page documents the result of that investigation.

The work was primarily performed by Ben Kero & Hal Wine - personal pronouns likely refer to one of us.

At this point there is not a real benefit to Mozilla deploying our own Github Enterprise (GHE) server.

Assumptions

These assumptions were valid at one time. They may no longer be relevant, but I am not aware of changes at this time.

1. B2G partner obligations require Mozilla to maintain public repositories.
2. B2G partner obligations preclude Mozilla from changing existing URLs.
3. At least one B2G partner explicitly ruled out use of github for hosting of public repositories.
4. We will continue to want to mirror far flung repositories used by b2g to ensure availability to automated builds.

The following assumptions are based on other projects currently underway or proposed:

1. Mozilla will use Review Board for code reviews, and not use that github feature either on github.com or GHE.
2. Mozilla will prefer "auto land" to individual developers landing commits, especially when they need to land on multiple branches.
3. Mozilla will continue to use bugzilla for defect tracking for (at least) Firefox and Gecko.

GHE Deployment Options

There are several deployment architectures possible with Github Enterprise (GHE). Each architecture comes with a different initial price tag and operational cost. Each also adds or replaces a different set of current Mozilla capabilities.

What GHE does not do

There are two things installing GHE will not do. At least not without revisiting some assumptions.

1. Eliminate the need to operate git.mozilla.org with non-GHE software. (We use gitolite currently.)
2. Eliminate the need for vcs-sync (mirror mode operation)

What GHE can do.

The two deployment scenarios that we considered are:

1. Land on GHE: Everyone who can commit to github.com can commit to GHE. We have roughly 400 developers (Mozilla + Mozilla-b2g orgs) committing to github. The license cost would be approximately $90K/yr.
2. Merge to GHE: Only automation and key individuals (sheriffs) can commit to GHE. If we keep the number of key individuals to 60 or under, the license cost is approximately $5K/yr/20 seats.

In both of these scenarios we are really talking about using GHE as a Git server and the canonical repo. We are not talking about using GitHub tooling in the same way that it is used on github.com

Notes:

• In both scenarios the repositories on GHE will not be publicly visible. (This is a restriction of GHE.)
• The key variable in GHE licensing costs is the number of seats available. A "seat" is an account used to access the GHE server for either reading or writing.
• The license fees are in addition to operating costs of the servers. Those operating costs were not estimated.

Land on GHE

This mimics, to a certain extent, the workflow of landing on github.com. There would be some differences, as community contributors would not be able to open a pull request directly against the destination repository on GHE. All GHE repositories are the equivalent of private repositories on github: they are accessible only to account/seat holders users.

When auto land is deployed, this restriction becomes much less of an issue.

Merge to GHE

This approach embraces and extends current practices of developers landing on a "*-inbound" branch. Sheriffs then merge/uplift/rebase the changes onto the "release branches". I believe a strong case can be made for the VCS workflows needed by developers being different than those needed by release. (That's why our rules for modifying code are so different after code leaves m-c.)

Technical Findings