Recent posts on my blog have talked about the difficulty submitting changes to Firefox and the rise of GitHub. I encourage you to stop reading this post and read them now if you haven't already.

As I was looking at the list of process debt contributing to Firefox, one thought kept creeping into my mind: how many of these items go away if we utilize GitHub?

As I mentioned in these two posts, GitHub's popularity has essentially commoditized many items on this list, especially the parts around source control and submitting patches for consideration (just fork and open a pull request). It seems that everyone these days is on GitHub and asking people to use GitHub to send changes to Firefox would almost certainly be well-received by contributors and even Mozilla staff.

Here's what I think: Mozilla should utilize GitHub for Firefox development.

The verb in that sentence is important: I purposefully said utilize and not something like switch to. To switch or not to switch to GitHub for Firefox development is a false dillemma and a logical fallacy. So is the question about switching to Git. As I explain later, there is a spectrum of options available and switching or not switching are on the extremes. Utilize doesn't preclude a binary switch or don't switch outcome, but it does keep an array of options on the table for consideration.

So, how should Mozilla utilize GitHub for Firefox development?

I think that insisting people establish Bugzilla accounts and upload patches to Bugzilla/bugs is an anitquated practice in desperate need of an overhaul. I think that if someone has written code, they should be able to essentially throw it over a wall to initiate the change process. They should be able to do this in a manner that incurs little to no process debt. We, Mozilla, should be able to take only code and integrate it into Firefox, assuming a trusted person - a module owner or peer - agrees and grants review. GitHub pull requests would facilitate a lesser-involved code contribution mechanism.

Another benefit of GitHub is that the web interface goes further than just code submission: they also have facilities for editing files. It's possible to edit a file in someone else's repository and create a pull request direct from the web interface! My post on process debt began by comparing the process of edit a wiki versus the current Firefox change process. GitHub's web-based editing essentially reduces the gap to cosmetic differences. GitHub's ease of contributing purely via the browser would open the door to more contribution for lesser-involved changes (sometimes referred to as good first bugs).

To state it explicitly, I support the use of GitHub pull requests for submitting changes to Firefox.

Now, there are some concerns and challenges about doing this. These include:

• Fragmentation of code review and tracking could be problematic for Mozilla staff and other highly-active individuals.
• GitHub can lose some parts of code review after rebasing and force pushes. Edit: Comments below indicate this is no longer a problem. Great!
• You can only assign 1 reviewer per pull request.
• GitHub sends an email/notification per review comment. This can be extremely annoying for some mail clients.
• GitHub doesn't have a mechanism for dealing with security bugs.
• Data sovereignty concerns (all data hosted on GitHub and subject to their data retention and access policies). Their API has query limits, which can limit machine use somewhat.
• GitHub's model favors merges over rebases. Merges have a number of downsides, especially for large projects, and we strongly prefer to maintain our mostly-linear Firefox repository history.
• GitHub's model favors appending commits rather than rewriting commits. (This is due to Git badness when you force push.) Mozilla favors a world where the final commit is what's reviewed and landed.
• Git != Mercurial. Firefox is canonically stored in Mercurial. There is some impedence mismatch here. But nothing tools can't overcome.
• The Merge Pull Request button is almost completely useless for Firefox's existing and future workflows. This partially invalidates other niceness the pure GitHub pull request workflow buys you.
• Everything is lumped into a single bucket. We lose component-level subscriptions, making following harder.
• Following the entire Firefox project on GitHub would produce an overwhelming fire hose of data.
• We don't control GitHub and our options for extending it to extract even more process optimization are limited to what their APIs support and what they choose to implement.
• We are at the whim of GitHub should they ever change a feature or API.
• See also Servo's list of challenges.

Some of these issues can be overcome by tools and automation (which I would happily build in my capacity as a Developer Productivity Engineer at Mozilla). Others are more fundamental and seemingly would require buy-in and/or support from very senior Mozillians.

If Mozilla were to go forward utilizing GitHub pull requests for Firefox, I think it should be done incrementally rather than going all-in and attempting the entire GitHub workflow from the start. Although, this would mean diverging from GitHub's well-known practices, which would increase process debt from the GitHub base level. I don't like that. But I think it is a step in the right direction. Partial reduction in process debt is better than no reduction.

What do I mean by incrementally start accepting pull requests? Well, I don't think code review should initially be conducted on GitHub. When you look at the above list of concerns, many of them are around code review and interacting with pull requests. I think there's too much badness and risk there to make me comfortable about moving things to GitHub and giving GitHub exclusive domain over this important data, at least initially.

But if code review isn't conducted on GitHub, what's the value of a pull request? A pull request would be a well-defined and well-understood mechanism for importing data into Mozilla's systems. For example, submitting a pull request would automatically result in the creation of a review request on MozReview or even a bug/attachment/review on Bugzilla. This would allow people to send code to Mozilla easily while simultaneously allowing Mozillians to use familiar tools and processes without the aforementioned concerns with GitHub. That appears to be win-win.

Once we have a simple mechanism in place for turning pull requests into MozReview's review requests, we can start playing around with the syncing of code review activity between Mozilla and GitHub so review activity on either system results in cross-posting. There is precedent for this today. GerritHub has bi-directional syncing of code review activity between GitHub and Gerrit. Facebook also does something similar, syncing data between their internal Phabricator instance. Mozilla to GitHub sync would not be difficult: we control all those systems and I'm pretty confident in our ability to make a GitHub API call when a MozReview review request is updated (we already make Bugzilla API calls, so we know this works). GitHub to Mozilla is a bit more difficult. But, others have done it: I'm confident we can too.

I see bi-directional syncing of GitHub pull request / code review data between GitHub and Mozilla as achievable and relatively free from controversy. I think we should experiment with this sometime in 2015, probably in Q2, once MozReview is in better condition to host GitHub pull requests. Although, supporting Git in MozReview is on my Q1 goals list, so maybe I sneak this into Q1. Time will tell.

At this time, I believe using GitHub for the ingestion of proposed Firefox commits into existing Mozilla systems should be the limit of Firefox's GitHub presence, at least as far as day-to-day development goes. If other groups want to use GitHub more actively and they find a way to make that work while placating everyone who cares, power to them. But I think moving the pendulum any further toward GitHub - including things like making GitHub the exclusive location for code review data, utilizing GitHub Issues, and making Git[Hub] the canonical Firefox repository - remain difficult and controverial propositions. I believe each of these to be medium to high cost and risk with low to medium reward. I believe it would be wise to defer these questions until we have data about the value of GitHub pull requests for Firefox development.

To summarize, I propose using GitHub pull requests as an alternate, supported front end to the code contribution pathway. We would eliminate a lot of process debt for non-Mozillians by supporting a known process. Mozillians on the review and code submission side of the process shouldn't have to worry about change because, well, it shouldn't matter if a commit came from GitHub or elsewhere: it will all appear mostly the same. I'm not saying that we will never expand our utilization of GitHub for Firefox development beyond this scope. But I am saying that I don't think it would be prudent to do so today.

And that's how and why I think Mozilla should utilize GitHub for Firefox development.

Addendum

While I'm here, it's important to note that GitHub does not and will likely never solve many items from our list of Firefox contribution process debt. GitHub is not a build system nor a tool for running and analyzing code and tests. We still have many, many deficiencies and usability concerns here. We have historically under-invested in this area and utilizing GitHub in any capacity won't address these other issues. In addition, Firefox is a magnitude larger and more complex than the vast majority of projects on GitHub. We will always be burdened with the cost of our success - of coping with and maintaining the additional complexity associated with that scale. Firefox is at least the 0.1%. There's a good chance GitHub and/or many of the amazing services associated with it (like Travis-CI) won't scale to our needs. I'd love to be proved wrong here, but the reality is supporting a marginal use case like Firefox likely isn't at the top of goals for GitHub and related organizations unless it is in their business interest (read: financial interest) to do so. One can hope that as these companies try to capture more of the enterprise market via offerings such as GitHub Enterprise that they invest in the features and scalability that large projects and organizations like Mozilla and Firefox need.