Topic on Talk:GitLab/2020 consultation

One topic that has come up in this consultation is Gerrit improvements. Why can't we make improvements to Gerrit to fix our problems with it? Isn't Gerrit upstream making improvements?

I've added some additional rationale that I felt was missing from this proposal to a subsection to the "Why" section of the document. This hopefully explains my perspective as someone involved with both the GitLab proposal and as someone who's involved with the maintenance of our Gerrit install.

The core of the issue is that we are rather singular in our use of Gerrit. The other companies running Gerrit are Gerrit developers -- this is the level of familiarity required to perform administrative tasks and add features. Maintenance and upgrades (in my limited experience) require non-trivial interaction with upstream to perform.

Simple improvements like avatars, renaming users, or renaming repos are either not support at all or implemented via plugins with varying levels of support. Bigger improvements I'd like to see like two-factor authentication and anti-vandalism tools are not on the upstream roadmap at all as many installs are either protected by Google's authentication or behind firewalls. We are the only large open install using LDAP authentication which I worry about constantly.

Further, upstream technical decisions (as is likely true for any project) are sometimes questionable. One technical decision that, collectively, the Gerrit community is still realizing the ramifications of is forgoing a traditional RDBMS in favor of NoteDB. This has led to multiple problems ("external id already in use" for example) and is somewhat broken for our use by dint of an upstream bug that has been open for 2 years at this point.

All of the above is to say that while I see Gerrit improving in its UI and UX, administration is difficult and key features are lacking and I see little reason to believe they'll ever be addressed. Should we stay with Gerrit, we need a non-trivial dedication of resources to drive forward any new features we'd like to see.

Thanks for this context and rationale, @TCipriani (WMF). Do you feel like we could get to the point where our Gerrit instance has the features used on https://gerrit-review.googlesource.com or is this an example of what you're talking about where there is not a lot of documentation or guidance for non-Gerrit developers to reach this level of polish and integration? Specifically, looking at a patchset from their gerrit instance https://gerrit-review.googlesource.com/c/gerrit/+/282695 there are some things that I think could make the developer / user experience quite a bit nicer for us:

• Using a "Checks" tab to report back the Jenkins job results, with the ability to re-run
• Separating "Code Style" from "Code Review" in the votes
• "Turn to take action" e.g. hover over the owner/reviewers on https://gerrit-review.googlesource.com/c/gerrit/+/282344 (https://gerrit-review.googlesource.com/Documentation/user-attention-set.html)
• the performance seems substantially better on their instance (sorry for such a vague metric, looking at console it seems like there are a few hundred ms of difference in various loading times but it seems to add up subjectively into a more pleasant experience when navigating files and patches)

• Using a "Checks" tab to report back the Jenkins job results, with the ability to re-run

This is part of the checks plugin as I understand it, which is part of a CI system that upstream has been using for a bit. I think we'd have to write our own plugin if we didn't move to that CI system to get our own version of that.

• Separating "Code Style" from "Code Review" in the votes

This is a custom label, and could be done quickly/easily.

• "Turn to take action" e.g. hover over the owner/reviewers on https://gerrit-review.googlesource.com/c/gerrit/+/282344(https://gerrit-review.googlesource.com/Documentation/user-attention-set.html)

Actionsets are a cool feature that are present in an as yet unreleased version.

• the performance seems substantially better on their instance (sorry for such a vague metric, looking at console it seems like there are a few hundred ms of difference in various loading times but it seems to add up subjectively into a more pleasant experience when navigating files and patches)

This could be a few things:

1. This could be a Gerrit instance closer to you than our instance in Virginia
2. There is an experimental cache that was recently discussed for the aforementioned unreleased version

These features are a good illustration that most of the other large gerrit installs are run by gerrit developers/have proprietary features (in the case of a multi-DC Gerrit, which is speculation from me). We don't run unreleased versions or experimental caches.

"We are the only large open install using LDAP authentication which I worry about constantly." +1

We really want to move authentication to OAuth ( https://phabricator.wikimedia.org/T147864 ) so we can benefit from two factor authentication, global deactivation of account etc. Eventually that will mean using https://idp.wikimedia.org/ a single sign-on portal based on Apache CAS which was recently introduced.

Could you shine some light on what specific security/anti-vandalism improvements you are thinking of? A topic further above seemed to indicate that the most common of those features that GitLab offers are proprietary and thus unusable to us.

Could you shine some light on what specific security/anti-vandalism improvements you are thinking of?

Sure! As I mentioned many of the comparable Gerrit installs are behind firewalls, so there aren't a lot of features that are built for instances where registration is open.

• Up until recently banning a user required logging out all users. This took 5 years to get fixed upstream.
• There are no plugins for any form of 2-factor authentication.
• There is currently no upstream tool to revert all the actions of a single user.
• There is no upstream tool to revert the actions of a single IP.
• There is no tool to see all the activity of a single user or IP.
• Upstream plugins that enable rate-limiting only allows rate-limit SSH actions and not HTTPs actions; however, you can achieve the same things via SSH and HTTPs.
• There's no mechanism for individual users to report abuse, and likewise no abuse queue.
• There is no "sync" mechanism between our ldap and Gerrit: gerrit fetches information from ldap on first login and that's it. If we delete a user in ldap, we must also delete that user in Gerrit.

the most common of those features that GitLab offers are proprietary and thus unusable to us.

This refers to using recaptcha for registration? If we continue to use ldap (I'm assuming we would), then we wouldn't register people via this mechanism but rather via Wikitech.

Being able to edit and delete your own comments would be very useful.

There is no tool to see all the activity of a single user or IP.

Yeah, lack of any kind of user audit functionality is a big problem not only in terms of anti-abuse but also for things like community management (is this user a good CR+2 candidate?), mentoring and productivity (would be nice to be able to do a quick review of what work I did this week or month, but in Gerrit that's pretty much impossible). Upstream is not super interested in fixing, either.

(In general, in my very superficial impression Gerrit upstream is rather unresponsive.)