Page MenuHomePhabricator

Replace Gerrit with something usable
Closed, DeclinedPublic


I don't know if this is the kind of elephant in the room that everyone knows about, or if it's more of an Emperor's New Clothes scenario based on collective delusion, but the Gerrit interface is really, really awful. It is a massive turn-off to new users and a significant barrier to entry. Even basic things like finding a project or posting a comment are frustratingly difficult.

As someone who has worked on Wikimedia projects since 2003 I am very familiar with the code, processes, history, ethos and community around MediaWiki development. Even so, I completely disengage when confronted with the Gerrit interface for code review. It was one of the main reasons that caused me to step away from active development, and even now - nearly half a decade later - nothing seems to have changed.

In 2012, Gerrit was evaluated. The two top criteria for a code review tool were:

  • It must not be ugly
  • It must be reasonably intuitive and user-friendly

Gerrit fails catastrophically on both of these criteria. To be honest, I have no way of telling how well it meets the more functional requirements, because I can never find the functionality I need.

For example, I was just asked to code-review a trivial improvement to an extension I wrote. Having followed the link in the e-mail, it took me a minute or so to find what might be the right button to add a comment (`it appears that you 'reply' to a commit, rather than commenting on it, which is a curious concept). For some reason this button is located in the middle of the header. I couldn't figure out how to actually see the changes in the commit (thankfully the diff was included in the e-mail). Having replied it took me another minute to figure out where my comment had actually gone (down the bottom, nowhere near the box you just interacted with, collapsed so you can't see it). In the process, I found another comment that might have affected what I wrote if I had managed to find it beforehand. I still have no idea how to 'approve' the commit, as requested.

I don't know if anyone here has used Github - you should check it out sometime. It'll blow your mind!

This post is a bit of a rant, but there is a serious point here - Gerrit needs replacing. It is not fit for purpose. It is a barrier against contributing and it is not likely to improve in future versions (it has demonstrably proved that over half a decade).


Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 13 2017, 12:04 AM

This should be declined as we will eventually go with differential but that's currently on hold.

Also note: gerrit is getting a new ui with gerrit 2.14 which has been released. They are calling it polygerrit and can be viewed at

HappyDog added a comment.EditedMay 13 2017, 12:10 AM

This should be declined as we will eventually go with differential but that's currently on hold.

Where is that ticket?

Also note: gerrit is getting a new ui with gerrit 2.14 which has been released. They are calling it polygerrit and can be viewed at

It's not massively full of whelm.

EddieGP edited projects, added Gerrit-Migration; removed Gerrit.May 13 2017, 9:27 AM
EddieGP added subscribers: EddieGP, mmodell.

This is what the whole project Gerrit-Migration is about. In addition to the link Reedy posted, also see

Unfortunately all of this is completely stalled at the moment (I described this at T130420#3203634) - and that has been so for a much too long time now (IMHO).

In T130420#3203775 on Sun, Apr 23 2017, @mmodell wrote:

@EddieGP: this is indeed stalled and currently we don't see any way forward. The status quo (gerrit) will likely remain for the foreseeable future.

While I can't agree more with the intention of this task (shutdown gerrit, move to "something else" - which would be differential) we already have this as a "project" of RelEng, there's Gerrit-Migration and a RFC exists. As far as I got it, there is no doubt about that we want to drop gerrit at some point - it's just not a priority at the moment (which I think is a great pity). So I don't think this task is a good place to make this a priority again or that this what is described in the description is still to be discussed. Hence I second Paladox here, it either should be declined (maybe not, it's not really that we won't do this) or marked as a duplicate of a tracking task for the migration.

Paladox changed the task status from Open to Stalled.May 13 2017, 10:01 AM
Paladox triaged this task as Lowest priority.
EddieGP removed a subscriber: mmodell.May 13 2017, 2:41 PM

(Just to note here, gerrit is getting a totally new ui starting with gerrit 2.14 (as a experimental ui) in 2.15 it is now supported and no longer experimental. GWTUI (gerrit's current ui + old ui) is stated to be removed sometime soon once polygerrit has added most of gwtui features. + polygerrit has more new features then gwtui.

You can view all the diffs in one screen like differential if you want to. You can also do reply when viewing the diffs.

It is easier to access projects with the more button leading you to projects and groups.

PolyGerrit is alot faster then GWTUI.

Here's a link to a survey for how you rate what is most important for you from a ui (when reviewing code).

Tgr added a subscriber: Tgr.Mar 30 2018, 2:43 PM

With T119908 declined, this is not really a duplicate anymore, and should probably be reopened or declined explicitly.

I'd argue for declining:

  • While Gerrit had crap UX historically, it was always very elegant on a technical level - it simulates a git upstream so you can access almost all of its power via plain git commands, without any tool. It also has a decent REST and SSH API. Phabricator's APIs, in comparison, are clunky, largely undocumented and hard to use in a secure but convenient way (no SSH-based authentication).
  • Polygerrit dropped the terrible reimplement-the-browser-in-Javascript approach of the previous GWT-based UI, chose a sensible design paradigm (material design) and metaphor (make reviews look kinda like email threads), and is responsive.
  • Polygerrit has improved a lot since inception, and can be expected to improve more as Google has adopted it for major projects and has thrown a lot of resources behind it (including UX professionals). 2.15 fixes most of the annoyances I can think of and makes the experience a bit more similar to Github review threads (filter out noise in review conversations, hide resolved comments, add descriptions for patchsets, ability to ignore / mark as reviewed) and has an inline code editor that looks OK.
  • Even apart from all that, it's not like there are any other good alternatives out there. Phabricator is now officially declined, and in any case its non-Maniphest parts always felt like an afterthought; Github is unacceptable to a large faction of MediaWiki developers on FLOSS and privacy grounds; Gitlab only supports rebase workflows in its enterprise edition.
EddieGP changed the task status from Duplicate to Declined.Apr 1 2018, 7:39 PM

I agree with @Tgr. In my experience gerrit is a tool that really is a very good fit for our workflow(s), albeit with a crappy user interface. So far I'm not aware of any alternative that has a substantial better user interface without requiring notable changes to our workflows (like would have to be done and failed to happen when adopting diffential) or our basic principles (e.g. any service not hosted by the foundation would be unacceptable because of the principle 'we can't deploy from a service we don't control').