toc

Phabricator

MozReview's system design coupled various functions, including a staging/review repository and autoland, with Review Board in an overly tight and restrictive way. Conduit's architecture of a set of loosely coupled services will make it easier to develop, expand, and maintain automation around Firefox engineering process.

Given that we need to extract, and in many cases rewrite, much of MozReview's functionality, we took a fresh look at code-review tools. After some analysis, Phabricator emerged as the best choice to meet our needs and address some of the problems in Review Board (in terms of both general user experience and some severe bugs in the diff view).

Thus the first milestone of the Conduit project is standing up a Phabricator instance. It will be integrated with BMO, although somewhat differently from MozReview. Most notably, Phabricator will support the reviewing of confidential patches. See more on BMO–Phabricator integration. This involves both operations, to deploy and configure the instance, and development, to build the integration pieces.

At the completion of this stage, we expect Phabricator to be rolled out to some smaller groups. MozReview will continue to be supported.

Patch-based Autoland

Given that Autoland is not just one of the more appreciated aspects of MozReview but also part of a larger process-security road map, our first custom service will be a new Autoland service. Whereas the engine that actually does the committing and pushing to repos (the "transplant service") is already a separate service, the logic and UI for submitting Autoland requests and reporting status was built into MozReview and will need to be rewritten. Rewriting this as its own service allows us more control of the user experience, since we are freed from the constraints of Review Board's environment and extension system. This new service is called "Lando" (and is technically two separate microservices, lando-ui and lando-api).

Since we want to deprecate MozReview as quickly as possible, to avoid having three competing code-review tools, Lando will be patch-based, that is, there will be no staging repo for commit submission. In order to fully support the engineering process, Lando needs to support confidential patches, and developing a commit-based system that can handle private commits is a tricky undertaking—one that we will address, but after we have basic autoland support working for all cases.

When this stage is rolled out, Phabricator and the new autoland services will be available for the use of all engineering. MozReview will be considered deprecated and will be made read-only soon after.

Staging repo for public commits

This release will bring us back to par with MozReview by supporting push-to-review and autolanding of commits to Try and integration/mainline branches. The system will be built in such a way that it can be extended to support confidential commits; however, for this phase confidential patches will still have to go through the standard Phabricator submission process (“arc patch” or the equivalent). This approach means we can work out any problems with the commit-based approach to review and autolanding.

Staging-repo support for confidential commits

By using Mercurial bundles as the storage mechanism for the staging repo, and adding access controls, we can support confidential commits, that is, commits that are only accessible to authorized users. In addition, this solves the "too many heads" problem that has plagued Try and would eventually affect MozReview.

At this stage, push support will be fully implemented regardless of the visibility of the patches/corresponding bug. The patch-based autoland will be considered deprecated, and may be fully removed. Standard Phabricator patch submission will be left enabled primarily to support projects that do not use a staging repo (e.g. projects stored in git repos) that wish to use Phabricator for code remove, perhaps in order to support confidential reviews.