Wikimedia Gitlab Migration Status

Gitlab minimum viable product policy makes it less and less attractive among other CI/CD/SecOps tools(and this makes me sad because I loved it back in the days). Instead they focusing on AI when the rest of features are unfinished. For example lately I wanted to implement deployment approval flow for ours crucial repositories but stumbled onto nasty bug. I've created a support request as we are on premium plan. The agent pointed me to 2-years old issues and closed the ticket. This is how its done there

The key bits:

> we believe that we should stop migrating all repositories unconditionally, and instead keep our two systems: Gerrit and GitLab. Gerrit should remain for the use-case of deeply connected repositories. GitLab should remain for tools, analytics and machine learning, and services.

> GitLab’s missing features are necessary for the productivity of developers, deployment safety, and operational reliability.

> There’s a demand for code hosting outside of Gerrit. Wikimedia Foundation-hosted GitLab has been a boon for these users—tool creators, engineers focused on data and analytics, and folks building services.

(of course, read TFA for the finer details and rationale)

> Without a way to coordinate merges cross-repository, we would see more CI failures and broken builds due to semantically incompatible patches landing on the mainline branch.

Isn't this rather a symptom of code organization or architecture issues? If one needs to coordinate merges of individual parts, doesn't it mean they belong together? Monorepos or clearer versioning of the individual parts would enable independent merges.

Regarding their point on stacked diffs[0]: they're such a great feature imo and it's a shame GitHub etc don't support the functionality better.

Often I'm working on a set of changes that ultimately have a large code diff. I don't think huge PRs are often a great idea as they introduce more risk, so it's often a good idea to break it up. But a reviewer is not always available to review each bite-sized PR, so you end up with a backlog of PRs that are ugly to review in the GitHub UI and you need to continually rebase them as each is merged.

I quite liked the graphite.dev workflow for this, but it's a bit pricey. That and it only seems to work well if you can get your whole organisation to buy into using it. If GitHub etc integrated it as a native feature, I think that'd be great.

[0]: As mentioned in the article, and https://newsletter.pragmaticengineer.com/p/stacked-diffs

Some background that I am familiar with because I worked on the team that maintains Wikimedia's Gerrit, GitLab, Phabricator, CI and deployment systems. I left in 2022, however, by then the GitLab migration was well underway.

As far as I remember, and from what I observed, the decision to adopt GitLab was meant to better cater to newcomers and volunteers who generally do not appreciate Gerrit and saw it as a serious barrier to engaging with the Wikimedia software development ecosystem. Gerrit has a pretty steep learning curve and the web interface is pretty ugly (Subjective, but this is an opinion shared by many.) We got quite a bit of feedback that Gerrit was a stumbling block for new contributors as well new hires on the Product and Engineering teams. Many folks who have used Gerrit for a long time learn to love it but newcomers either hated it or found it difficult to adjust to.

So to summarize the main arguments for GitLab (as apposed to "just use github" or various other alternatives which were considered):

* It's ostensibly open * It's similar to GitHub in most ways that matter * The GitLab CI system is configured in the repo and it's entirely self-service, as apposed to the mess that is Gerrit + Jenkins + Zuul CI. Zuul requires a lot of specialty expertise to configure and maintain, and that places control of CI largely out of the hands of the people maintaining each repo. Self serve is better for the needs of many if not most developers. * Last but certainly not least, there was a fairly wide-spread fear that Microsoft would ruin GitHub, along with and a strong preference for self-hosted free software tools in keeping with https://foundation.wikimedia.org/wiki/Resolution:Wikimedia_F...

Does it say anywhere why they chose Gitlab? I used to be a big fan of them, but they kind of died for me after they implemented big limitations on the free tier. I stopped being able to Trojan-horse it to my company, and Github got good CI and other nice features, so I've switched to that.

Just setup GitLab yesterday on my homelab server (containerized), it's a Rails beast and takes a while to start but the product they give away for free seems very polished. I looked at Gitea too before choosing GitLab, mainly for their CI.

GitLab was so great in the early days. But they started chasing after the enterprise market and stopped innovating. They dropped their cheapest paid plan, and features get introduced that no one wants and bugs don't get fixed.

Maybe this publicity will get them to rethink their strategy, but I doubt it.

To properly run gitlab with large codebase you must have a dedicated devops team to maintain extensive set of webhooks and other linked services. Even in top-tier enterprise edition.

Gerrit is like old school git, the flexibility of github and gitlab far exceed gerrit's use in my opinion.