GitLab/Migration status/FAQ

Anticipated questions about the status of our GitLab migration.

Where should my repository live? Or, How can I know where my thing should/must live?

MediaWiki core and the subset of extensions and skins which track MediaWiki core’s mainline branch (including all Wikimedia production-deployed extensions and skins) should live on Gerrit.
SRE’s Puppet repository should remain on Gerrit as well as its dependencies and dependent repositories.
Other repositories may opt for either Gerrit or GitLab. Some factors to consider:
- Mental overhead of developers working on the project
- Dependencies in other repositories
- Number of collaborators to the project

Why not roll back to Gerrit only?

Why can’t we implement the features for GitLab that are lacking? It is “open”

We have implemented some features upstream and worked with upstream on mitigating problems:
- Phabricator/Phorge issue tracking
- Stacked patchset workarounds (gerritlab and glab stack)
But any feature we merge upstream must fit with the product direction of GitLab and is at the discretion of upstream to merge.
There is no way to add custom code to our installation without merging it upstream:
- There is no way to add any custom client-side code or even custom CSS.
- The security release cycle is rapid and comes without warning—all installations learn about security vulnerabilities at the same time as attackers. We requested advanced notice of security releases, but this was rejected. This decision hinders our ability to maintain patches on top of our installation while keeping it secure.

Why not just pay for GitLab / use gitlab.com?

The most important features—cross-repository merge dependencies, stacked/dependent merge requests— are not a part of any paid tier of GitLab.

Will we / when will we fully migrate everything to GitLab?

As of now, we do not intend to migrate everything. We may revisit this in two-years time.

What will we do now with MediaWiki CI / CI for things on Gerrit?

We will continue to use Zuul as a CI/CD system for Gerrit workflows, it will be upgraded to a new version that comes with a number of improvements

How settled are we that the Foundation should keep running both systems in the long run?

We would like to avoid revisiting this before some time has passed—two years is a deadline we need to hit for another portion of our stack. This time window would give our developers a useful mental model for making the decision about where their code lives; i.e., if the time window is too short, developers may opt for a non-optimal solution and “just deal with it for now.”
This is an ongoing process and we’ll continue to talk to developers and stakeholders.

Have we considered GitHub or some other forge?

We have not considered any other option at the same level of detail as both GitLab/Gerrit.
Due to resource constraints, we need to constrain ourselves to these two systems.
For now, we will not be evaluating any other systems or restarting the consultation process with a new code forge.

Did we consider creating a Browser Plugin or Customized workflows with Gitlab?

We have created some custom workflows, one of which GitLab is working on implementing internally. This is the stacked diffs/patchsets workflow. We met with GitLab to discuss the implementation. For the cross-repo merge trains we were stymied early-on by upstream bugs, but as GitLab’s development continues it may be worthwhile revisiting.

If lack of some core features is blocking us from migrating our largest, most active repos, why did we move ahead with GitLab in the first place?

We built a test instance for the purpose of the GitLab consultation, but not for extensive evaluation. It was only after extensive real world use that we were able to uncover key limitations which blocked migrating our largest repositories.