Phabricator/Plan

This plan to migrate our developer infrastructure to Phabricator consolidates the feedback received at Requests for comment/Phabricator, http://fab.wmflabs.org/project/view/14/, and other sources.

Summary
The result of the Phabricator RfC is favorable to move to this platform and replace gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello, and Mingle. A first phase will focus on migrating all the Bugzilla and RT data to Phabricator, and merge the project management work being done in Trello and Mingle. A second phase —that could be worked in parallel— will focus on substituting Gerrit for code review. There is also a possibility to deprecate Jenkins as a continuous integration tool, but this option is out of scope for now. A few blockers have been identified in these areas, and we will collaborate with the Phabricator community to fix them.

The calendar of the migration is conditioned by the resolution of these blockers. The current assumption is that Phabricator will deprecate Bugzilla, Trello, and Mingle first. Gerrit will follow after a period of transition.

The Engineering Platform team at the Wikimedia Foundation will lead this project allocating the resources necessary to define a detailed plan, proceed with the migration, and maintain the new infrastructure.

Requirements
A detailed list of short term tasks is available at the project Wikimedia Phabricator Day 1.

General

 * Users log in to Phabricator with their Wikimedia credentials.
 * Unified search powered by ElasticSearch.
 * IRC bots ported to Phabricator.

Task / bug management

 * Possibility to remove and delete comments.
 * All tasks under a private project (e.g. Security) must be private.
 * Interacting with external (non-Phabricator) users via email.
 * Migration of all Bugzilla and RT  data, leaving automatic redirects.
 * Gerrit plugin to notify back to Phabricator during the transition of code review tools.
 * Flexibility for teams to move from Trello, Mingle, and Gerrit within a window of deprecation.

For an analysis between Bugzilla and Phabricator, see Requests for comment/Phabricator/versus Bugzilla.

Code review
A complete list of tasks is available at the project Code review for Phabricator.


 * The code review process in Differential/Audit needs to be adapted to our needs.
 * Build a binding between Phabricator and Zuul (if Phabricator's replacement for Jenkins is not ready).

Migration plan
The current plan (in progress, see discussion):
 * 1) ✅ Deploy the Trusted User Tool using the Legalpad app only -- see https://legalpad.wikimedia.org (it will be merged with the main Phabricator instance by Day 1).
 * 2) Deploy a separate Phabricator in a production server only with Wikimedia SUL enabled for log-in testing.
 * 3) The migration of Bugzilla, RT, and a selection of projects in fab.wmflabs.org are required for Day 1.
 * 4) There is no mass migration from Trello and Mingle projects. Some teams are more interested than others in total / partial migration. One idea is to write the Bugzilla migration script with an abstraction layer that could be fine tuned for RT, Mingle, Trello.
 * 5) The migration of Gerrit and Jenkins is out of scope for Day 1.

Ending up with one more tool
Having fewer tools is the whole point of this exercise. The replacement of Bugzilla and Gerrit with Phabricator is an essential requirement of this project. The teams using Trello and Mingle understand that relying in these commercial services is not a long-term solution.

Lack of a detailed plan
The current working plan is good enough to provide a realistic vision supported by the community. The WMF needs an RfC resolution in order to allocate the resources needed to elaborate a detailed plan.

Why not improving our current tools
Phabricator offers a very good basis today, it is written in PHP, and their maintainers are very proactive. Bringing Bugzilla (Perl), Gerrit (Java), or Scrumbugz (Python) to Phabricator's level would require a lot more work, even if their maintainers would agree with such plan. Also, Phabricator is an integrated suite, which means the different components are intended to be used together. This encourages features like explicitly attaching tasks to code changes, mocks, etc. Although we can write or improve integrations like Gerrit Notification Bot, they will probably never be as seamless as a suite.

Some projects should test first
Yes, this is also our recommendation for the migration from Gerrit to Phabricator. About the migration from Bugzilla to Phabricator, it needs to be done at once because we cannot do a full migration of data with two moving targets.

Various UI issues
We can customize the CSS of our instance for more appropriate font sizes, colors, etc. Upstream has already fixed some of the problems reported.

Requiring arc
Arc checks new patches for basic mistakes before uploading them for review. This is useful for the majority of contributors and for the project. The occasional contributor can upload a patch directly via the Phabricator Web UI.

Phabricator is unfamiliar for most newcomers
New contributors are not necessarily familiar with Bugzilla and Gerrit either. Most of them come with GitHub-like expectations anyway. Offering them one integrated platform is better.