When I talk to Mozillians who now work at Facebook, they all say something similar: the tools at Facebook are amazing and put what Mozilla uses to shame. Having worked at places with decent tools, I do know that Mozilla is behind the times. So it was easy for me to dismiss these observations as obvious. But, when you start asking them about specifics, one tool they are quick to name is Phabricator.

For those who don't want to follow the link, Phabricator is your all-in-on software engineering web application and platform. It has issue/bug tracking, code review, repository navigation, wikis, etc. It's the kitchen sink for software lifecycle management. And, it's open source and easy to extend. Sounds promising.

After hearing Facebookers rave about Phabricator and having casually interacted with an instance to review patches to Clang, I was keen to have a closer look.

So, I spent a lazy afternoon and installed Phabricator on an EC2 instance (connection details below). Having interacted with the default setup for a few hours, I can say with high confidence that the Facebookers can back up their claim that Phabricator is pretty damn amazing. My initial impressions are that it's one of those tools that's so good that once you start using it, you'll never tolerate anything subpar again. Again, hearing the Mozillians-turned-Facebookers opine about Bugzilla, code review, etc, I think this initial impression might be right.

In the sections below, I'll talk a bit about Phabricator and why I think it is superior to what Mozilla uses.

Integrated UI

One thing I really love about Phabricator is the integrated UI. Phabricator is essentially a collection of applications tied together by a single web interface. So, everything is readily available under one site/domain/service.

This means everything is easier to find. You search for something and all the different components have their results surfaced. Contrast with Mozilla as of today, where you need separate searches for Bugzilla, MXR/DXR, wiki.mozilla.org, etherpad, MDN, etc.

For IT, it means there is only a single service to run and scale. Less overhead to operate. Less effort to secure.

Arcanist command line tool

Phabricator ships with a command line tool called Arcanist. It is amazing.

Projects put .arcconfig files under version control which contain the settings used to configure Arcanist for that project. They essentially point back towards the Phabricator instance for that project.

You can do a lot with the Arcanism command line interface. Want to create a code review? arc diff. It opens up an editor and allows you to fill in details about the review. It then automatically publishes it for review. No leaving the command line necessary.

You can download and apply patches undergoing code review by specifying their review identifier. e.g. arc patch D1.

You can create tasks for yourself by running arc todo. The tasks are uploaded to Phabricator automatically and show up in your dashboard.

If your repo has configured which tests apply to which paths, arc unit will run all tests impacted by the current patch. (If we ever get around to annotating this, it would significantly reduce load in automation by eliminating unnecessary tests.)

There is an arc land command to land patches on the appropriate landing branch.

Arcanist abstracts the differences between version control systems pretty well. You can use the same commands for Mercurial, Git, or Subversion.

Arcanist is pretty nice. It reminds me a lot of mach and what I originally wanted mach to become with regard to helping to improve developer workflow.

Real Code Review

Phabricator features a real code review tool - Differential.

Things like interdiff actually work. It integrates with the code repository, which means you can expand context right from the review interface. It can detect blocks of code that moved between files. It has a nice file tree for navigating changed files (optional feature). It hides whitespace only changes by default. You can specify a group of people for review and reviews will show up in the dashboard of individuals in that group. It has a flag to say whether a patch underwent linting before upload. (You can configure linting through Arcanist and have your patches linted before upload. If you properly deploy linting, style nits all but go away. As I like to say, every time I write a style nit in code review, my time is wasted and Mozilla is throwing away part of my salary.)

Mozilla is apparently integrating ReviewBoard into Bugzilla. This is good. ReviewBoard's review features are infinitely better than Splinter (Bugzilla's current review interface). However, ReviewBoard is mostly a standalone tool. What makes Phabricator's approach better is that code review integrates tightly with everything else. This enables some pretty awesome scenarios. Keep reading for more.

Auditing

An interesting and potentially very useful feature of Phabricator is auditing. Where Differential handles pre-push code review, the Audit application supports post-push code review. You may say but all changes at Mozilla must go through pre-push code review - there's no use for post-push code review. Yes, but post-push review opens up a whole new realm of possibilities.

It's possible for individual users or projects to set up rules to automatically trigger audits. For example, as build module owner, I'm very interested in ensuring people follow the code review policy of having a build peer review changes to make files. With Phabricator, I was able to easily configure a rule that automatically creates an audit every time a make file has changed but it wasn't signed off by a build peer. Front and center on my dashboard are a list of commits that I should probably look at. Neat!

Audits are potentially useful for reviews that focus less on code. For example, Firefox Health Report and Telemetry are two Firefox features that collect data and send it (anonymously) to Mozilla. Audits could be used to flag a privacy review when probes are changed. We often don't want this privacy review to hold up code landing. But we do want to track that this review occurs before a patch is shipped to our Beta channel users. I think audits would be great for facilitating this.

Of course, there is a web interface to create new audits. Any individual can watch anything they have access to. No process involved. Just log in and create a rule.

Mozilla has audits today, but it isn't user intuitive. They commonly take the form of Bugzilla keywords or whiteboard entries. Phabricator's feature is much more powerful.

Creating rules as a result of actions

Phabricator has an application called Herald that allows users to install rules to do something as a result of an action.

For example, I can create a rule against new review requests that will CC me or automatically add me as a reviewer if a certain file is touched by a patch.

I can have Phabricator email me whenever a specific user makes a commit or when a commit touching a specific file is made.

This feature is self-service. You just open the web interface and program custom rules to your heart's content.

Herald is insanely useful. To my knowledge, Mozilla has nothing quite like it today. I wish we did. If Mozilla doesn't official deploy Phabricator, I may continue to run my own personal instance just so I can have this feature.

Of course, there's an Event Listener API so you can write your own events and rules. The sky is literally the limit here. For example, we could have all uploaded patches automatically submitted to Try so they run the release automation gamut. And, we could have Phabricator's background daemons poll for try results and report them directly in the web interface!

Module ownership defined inside Phabricator

Phabricator has a modules concept built into it called Owners. You create a package that has a single owner and a number of members. This package can be associated with multiple repositories and individual paths inside repositories.

The power of this feature is realized when it is integrated with other components of Phabricator.

For example, there is a checkbox for each package where you can automatically have Phabricator ensure that a package member is involved with code review touching files belonging to a package. It will also automatically report commits not reviewed by members of a package. How insanely useful is that!

Other applications and features.

Phabricator ships with a number of other applications and features.

There's a blogging platform called Phame.

There's a simple wiki called Phriction.

There's a simple polling application called Slowvote.

There's a mechanism to upload and view files.

There's a pastebin-like application called Paste. It integrates with authentication and authorization, so you can limit the audience of pastes.

There's a JSON over HTTP API that allows you to do nearly everything. (I assume this is what Arcanist uses for everything.)

There's a built-in badges mechanism called Tokens.

You can exchange messages and chats with other users (similar to IRC) using Conpherence.

There is a question and answer application called Ponder. People ask questions and other people answer them. You can search questions, of course. This helps build up a searchable knowledge base.

There is a mockups viewing and collaboration tool called Pholio. You can upload mockups as photos and then annotate images through the web interface. e.g. you can create a rectangle and ask a question about what you see in that rectangle.

There is a time tracking application called Phrequent.

Phabricator can receive inbound email to update issues, reviews, etc. You can even file new bugs via email! Having used an email interface to Bugzilla at a previous job, I can say from experience this is extremely useful.

Phabricator allows you to cherry pick which applications you have enabled. Want just code review and repository browsing without issue tracking? You can do that.

Test instance for Mozilla

As I alluded to above, I have installed an instance of Phabricator on EC2. My intention for this instance is for Mozillians to start playing with it and seeing if it's something they'll like.

The test instance is available at http://phabricator.gregoryszorc.com/.

You can log in using OAuth with one of the configured service providers or by creating an account. Please note that I'm only serving on plain HTTP, so your password are sent in the clear.

I have configured a few popular Mozilla repositories with the install. It's easy to configure new repositories. Send me their info and I'll add them!

While the web UI is nice, Arcanist is essential to get the most out of Phabricator. To get arc working with your machine, follow the official instructions to install Arcanist. For your .arcconfig file, use something like:

{
  "project_id": "gecko",
  "conduit_uri": "http://phabricator.gregoryszorc.com/"
}

Then, have Arcanist fetch authentication credentials:

$ arc install-certificate

From there, run arc help and see what you can do!

Of course, you'll need to adjust the project_id when appropriate.

When you use this Phabricator instance, please keep the following in mind:

• I'm hosting this on my own dime and have the most powerful EC2 instance I felt like paying out of pocket. That instance sadly isn't powerful enough. I installed Phabricator on my desktop at home and it flies like a rocket ship. Please don't blame slowness on Phabricator.
• I didn't even attempt to tune the HTTP or MySQL servers yet. Expect more slowness.
• The service and all the data inside could go away at any time. I don't have monitoring of the service (yet). Use at your own risk.
• At the time I wrote this, Phabricator was still indexing some repositories, notably mozilla-central. Anything interacting with source navigation appears to be slow as a result.
• The install is effectively a vanilla, out-of-the-box install. Things like Mozilla styling could presumably be added. There are likely also many sub-par configuration settings. Leave comments and I'll see about changing things.
• The front page insists on a sign-in. However, I believe all of the content should be accessible to the public. Contact me if you know of a way to fix this!
• This could be hooked up with Persona. I couldn't find a Persona auth provider and coding one is beyond my current PHP skills. If someone writes one, let me know and I'll install it!
• I could hook up authentication against Mozilla's LDAP server. However, I don't want your Mozilla credentials going to my personal server nor traveling over the wire in the clear.
• I'm not an expert on Phabricator. I'll try to help where appropriate. But don't count on me being a support desk.

Next steps at Mozilla

How should we use Phabricator at Mozilla? Good question!

I encourage people to play around with my personal instance. Upload some patches. Perform some code reviews. Set up Herald rules to notify you of repository change events. Just keep in mind that I don't guarantee an SLA for my instance. So please don't rely on it.

I anticipate that people will come to the conclusion that Phabricator is awesome and that Mozilla should install an officially supported instance on a mozilla.org domain with proper hardware. I'll likely be reaching out to IT shortly to see how feasible that is. But, I imagine it will get shuffled to the bottom of the priority queue unless people make noise. If you like Phabricator, tell other people about it. Let your management chain know how amazing it is. If enough of or the right people clamor for it, priorities can get changed.

I hope you enjoy Phabricator!