Code Contribution – Firefox

First up, I’m going to be looking at what you need to do to get your code accepted into an open source project. I decided to start with Firefox since it’s huge, well known, and has a well designed procedure for bug submission. So, how does it work?

First, all changes are made in response to a bug on https://bugzilla.mozilla.org (if one doesn’t already exist for your change, you’d want to create one). Secondly, the code review is done on https://phabricator.services.mozilla.com. Contributors are encouraged to break down large submissions into multiple smaller patches, a very sensible policy that makes things easier to review. Furthermore, they require that (most) new patches be run through an automated testing suite before they’re allowed into the tree. I’m very much in favor of a policy like this, and in the past, I’ve even written automated testing suites for personal projects with no other contributors. Manual testing is important, but a proper automated test can find a lot of flaws faster than a human can (and can certainly find things that a human might miss).

So, once the code is submitted and tested, what’s next? A module owner (or one of their designated peers) needs to review it. What’s a module owner/peer? Basically, Mozilla has specific people that specialize in specific projects, and they approve patches for those projects (though Firefox itself is a single module). In most cases, the module owner/peer will request some changes for the project, and there will be some back and forth until the patch is accepted. After that, the patch is marked with a specific keyword that indicates that it’s ready to be committed (and someone should shortly come along and commit it).

How does this all work out in practice? I picked an almost comically simple submission to look at: https://phabricator.services.mozilla.com/D44520. In this case, someone who isn’t a module owner/peer marked the patch as requiring changes, and then once the changes were made he added a module owner to the bug as a reviewer, for final approval. The entire process took four days to complete – which might seem slow for such a tiny change, but you have to keep in mind that Firefox is a massive project with many contributors and thousands of open bug requests. Four days is faster than I was expecting for such a project, and you have to keep in mind that even small changes can cause problems if they’re carelessly made.

All in all, Firefox’s patch submission process seems very sensible. If I was starting a new open source project, I would definitely consider using some of the same ideas. However, the fact that they have their source code on one site, their bug tracker on another, and code review on a third made it difficult for me to figure out what was going on at first. I can definitely understand why a project of this size would want to have things separate in this manner, but for a smaller project I’d probably prefer a more condensed solution.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: