From Gerrit to Gitlab: join the discussion
By Tyler Cipriani, Manager, Release Engineering
There is a lot of Wikimedia code canonically hosted by the Wikimedia Gerrit install. Gerrit is a web-based git repository collaboration tool that allows users to submit, comment on, update, and merge code into its hosted repositories.
Gerrit’s workflow and user experience are unique when compared to other popular code review systems like GitHub, Bitbucket, and GitLab. Gerrit’s method of integration is focused on continuous integration of stacked patchsets that may be rearranged and merged independently. In Gerrit there is no concept of feature branches where all work on a feature is completed before it’s merged to a mainline branch—the only branch developers need to worry about is the mainline branch. The consequence of this is that each commit is a distinct unit of change that may be merged with the mainline branch at any time.
The primary unit of change for GitHub and other review systems is the pull request. Thanks to the proliferation of GitHub, pull requests (synonymous with “merge requests”) have become the defacto standard for integration. The type of continuous integration used by Gerrit can allow for more rapid iteration of closely aligned teams but might be hostile to new contributors.
Following an announcement in 2011, in early 2012 Wikimedia moved from Subversion to Git and chose Gerrit as the code review platform. The following summer a consultation resulted in affirming that Wikimedia development was staying on Gerrit “for the time being”. Since 2012, new Open Source tools for git-based code review have continued to evolve. Integrated self-service continuous integration, easy repository creation and browsing, and pull requests are used for development in large Open Source projects and help define user expectations about what a code review should do.
Gerrit’s user interface has improved — particularly with the upgrade from version 2 to version 3 — but Gerrit is still lacking some of the friendly features of many of the modern code review tools like easy feature branch creation, first-class self-service continuous integration, and first-class repository navigation. Meanwhile, the best parts of Gerrit’s code review system — draft comments, approvals, and explicit approvers — have made their way into other review systems. Gerrit’s unique patchset workflow has a lot of advantages over the pull request model, but, maybe, that alone is not a compelling enough reason to avoid alternatives.
Enter GitLab
Earlier this year, as part of the evaluation of continuous integration tooling, the Wikimedia Foundation’s Release Engineering team reviewed GitLab’s MIT-licensed community edition (CE) offering and found that it met many of the needs for our continuous integration system—things like support for self-service pre- and post-merge testing, a useful ACL system for reviewers, multiple CI executors supporting physical hosts and Kubernetes clusters, support for our existing git repositories, and more.
GitLab has been adopted by comparable Open Source entities like Debian, FreeDesktop.org, KDE, Inkscape, Fedora, and the GNOME project.
GitLab is a modern code review system that seems capable of handling our advanced CI workflows. A move to GitLab could provide our contributors with a friendly and open code review experience that respects the principles of freedom and open source.
Feedback
As shepherds of the code review system, the Release Engineering team reached the stage of evaluations where we need to gather feedback on the proposal to move from Gerrit to GitLab. The Wikimedia Gerrit install is used in diverse ways by over 2,500 projects. To reach an equitable decision about whether or not GitLab is the future for our code hosting, we need the feedback of the technical community.
On 2 September 2020, we announced the beginning of the GitLab consultation period. We invite all technical contributors with opinions about code review to speak their mind on the consultation talk page.
From now until the end of September 2020 a working group composed of individuals from across our technical communities will be collecting and responding on the consultation talk page. Following this consultation period, the working group will review the feedback it has received, and it will produce a summary, recommendation, and supporting deliverables.
It’s difficult to make decisions collaboratively, but those decisions are stronger for their efforts. Please take the time to add a topic or add to the discussion — our decision can only be as strong as our participation.
About this post
Featured image credit: Vulpes vulpes Mallnitz 01, Uoaei1, CC BY-SA 4.0
