Wikimedia Is Moving To GitLab (mediawiki.org) 12
The Wikimedia Foundation, the American non-profit organization that owns the internet domain names of many movement projects and hosts sites like Wikipedia, has decided to migrate their code repositories from Gerrit to Gitlab. Slashdot reader nfrankel shares the announcement: For the past two years, our developer satisfaction survey has shown that there is some level of dissatisfaction with Gerrit, our code review system. This dissatisfaction is particularly evident for our volunteer communities. The evident dissatisfaction with code review, coupled with an internal review of our CI tooling and practice makes this an opportune moment to revisit our code review choices. While Gerrit's workflow is in many respects best-in-class, its interface suffers from usability deficits, and its workflow differs from mainstream industry practices. This creates barriers to entry for the community and slows onboarding for WMF technical staff. In addition, there are a growing number of individuals and teams (both staff and non-staff) who are opting to forgo the use of Gerrit and instead use a third-party hosted option such as GitHub. Reasons vary for the choice to use third-party hosting but, based on informal communication, there are 3 main groupings: lower friction to create new repositories; easier setup and self-service of Continuous Integration configuration; and more familiarity with pull-request style workflows.
All these explanations point to friction in our existing code-review system slowing development rather than fostering it. The choice to use third-party code-hosting hurts our collaboration (both internal and external), adds to the confusion of onboarding, and makes it more difficult to maintain code standards across repositories. At the same time, there is a requirement that all software which is deployed to Wikimedia production is hosted and deployed from Gerrit. If we fail to address the real usability problems that users have with Gerrit, people will continue to launch and build projects on whatever system it is they prefer -- Wikimedia's GitHub already contains 152 projects, the Research team has 127 projects.
This raises the question: if Gerrit has identifiable problems, why can't we solve those problems in Gerrit? Gerrit is open source (Apache licensed) software; modifications are a simple matter of programming. [...] Upstream has improved the UI in recent releases, and releases have become more frequent; however, upgrade path documentation is often lacking. The migration from Gerrit 2 to Gerrit 3, for example, required several upstream patchsets to avoid the recommended path of several days of downtime. This is the effort required to maintain the status quo. Even small improvements require effort and time as, often, our use-case is very different from the remainder of the Gerrit community.
All these explanations point to friction in our existing code-review system slowing development rather than fostering it. The choice to use third-party code-hosting hurts our collaboration (both internal and external), adds to the confusion of onboarding, and makes it more difficult to maintain code standards across repositories. At the same time, there is a requirement that all software which is deployed to Wikimedia production is hosted and deployed from Gerrit. If we fail to address the real usability problems that users have with Gerrit, people will continue to launch and build projects on whatever system it is they prefer -- Wikimedia's GitHub already contains 152 projects, the Research team has 127 projects.
This raises the question: if Gerrit has identifiable problems, why can't we solve those problems in Gerrit? Gerrit is open source (Apache licensed) software; modifications are a simple matter of programming. [...] Upstream has improved the UI in recent releases, and releases have become more frequent; however, upgrade path documentation is often lacking. The migration from Gerrit 2 to Gerrit 3, for example, required several upstream patchsets to avoid the recommended path of several days of downtime. This is the effort required to maintain the status quo. Even small improvements require effort and time as, often, our use-case is very different from the remainder of the Gerrit community.
"Movement projects" (Score:2)
You're just going to throw that in and leave it there, as if it means something?
You do know what an editor would do, don't you?
fix the interface? (Score:2)
> why can't we solve those problems in Gerrit? Gerrit is open source
You want to "solve the problem" of the interface which is as modern as Craigslist?
Isn't it easier to start with gitlab or gitea, and add the Gerrit functionality?
Re: fix the interface? (Score:5, Insightful)
The problem with a git based solution that is not GitHub is that they are not GitHub. Pretty much everyone that works in open source has to use GitHub for one reason or an other, but it a lot less likely for the other solutions.
Now that most developers had to learn the GitHub look and feel on how to get code reviewed and merged, they donâ(TM)t want to have to learn how to do it with Gerrit, or gitlab, or bitbucket, or phabricator, or ....
Code reviews are not a feature of git itself, it is always a private feature of the services around a git hosting system. As such GitHub has the benefit of having the most users. This in turn makes it that many open or private source projects that use GitHub require minimum training of new developers.
The other strength of GitHub is that because they are the largest a ones by far, they are also the first choice for third party developers to support. You want to use Jenkins with your Pull Requests? GitHub support is strong. You want your pull requests integrated in your IDE? Your IDE probably has support for GitHub PR, but probably not for Gerrit. The same goes for slack, Jira, and a plethora of other developer productivity tools.
Re: (Score:1)
And here I am, maintaining the same 102 open source repositories on both GitLab and GitHub simultaneously for really only 1 reason:
GitLab code review IS TERRIBLE!
"hosts sites like wikipedia"? (Score:1)
Yes, that's the term everyone uses for Wikipedia, "a hosts site".
Fuck off (Score:3)
“modifications are a simple matter of programming.”
Said like every cunt who thinks they've done the hard part of thinking up an idea, and its a devs job now to do the easy part of making that idea reality.
Re:Fuck off (Score:4, Informative)
"Simple Matter Of Programming" is rarely used other than ironically.
Now a third party can take your code offline (Score:3)
A major disadvantage of Github for a larger project with a lot of enemies (and Wikipedia does have enemies, mostly authoritarians who like to control what is published about them - including nation-state actors) is that a third party, Github, can take your code offline. Not only your code, but your merge discussions and other documentation.
No third party can ever be as interested in your code as you are, and third parties can be threatened with expensive lawsuits or simply extra-legal action to take your code offline.
Github is more convenient. It is not necessarily more survivable.
Re: (Score:2)
Re: (Score:1)
I'm pretty sure that being on GitLab wouldn't have saved the youtube-dl folks.
Re: (Score:3)
It depends on how someone chooses to use GitLab. GitLab is both a service and software (Enterprise or Community editions). If a group uses the GitLab service then they may be susceptible to the same issues they would be if they were using the GitHub service. Wikimedia is going to self-host the GitLab software on their own servers. They will not be beholden to a 3rd party service.
Why github-style "pull request" workflow? (Score:1)
I'm not sure why the "pull request" style code review workflow is so popular. This guy's blog entry discusses UI and technical issues with it, although it is very long: https://gregoryszorc.com/blog/... [gregoryszorc.com] He clearly understands how things currently work internally, and the issues with them much better than any other writeup I've encountered.
Personally I like gerrit's review style much better, although the above blog discusses the possibility of developing something even better.