30 ms·

Wikimedia is moving to Gitlab

889 points by input_sh 6y ago

q3k 6y ago
This is sad. In my experience, Gerrit is a much better code review system than Gitlab merge requests. But it is different from what people are used to.
- epistasis 6y ago
  What advantages do you see in Gerrit? Do they require a lot of experience in order to be realized?
  - q3k 6y ago
    Clear mapping of change request == commit, allowing for easy building of multiple in flight change requests, rearranging them by using git rebase, updating with push to refs/for/master. Easy diffing between states of the CR (patch sets), so you can see what changes since the last round of comments, even if it spanned multiple updates. This is the feature I miss the most from other code review systems - be able to easily work on another commit that bases on one that I just sent out for review (even starting review on the new while the parent still hasn't finished being reviewed!), and rebasing my current change as the parent change gets reviewed/updated. Possibility to send out a PR for review using just a push (change message in commit, push to refs/for/master%r=foo). Snappy and compact code review experience (no space wasted for whitespace, avatars, pretty buttons). Full coverage with keyboard shortcuts. Powerful review rule system based in Prolog, allowing for things like code owners, experimental subdirectories without the need for review, etc.
    - dionian 6y ago
      > Clear mapping of change request == commit, was forced to use Gerrit by a client. I could never get the hang of this, I like to do frequent commits on short lived branches and using vanilla git. I never wanted any more features other than a nice UI to encourage people to review.
      - q3k 6y ago
        The nice UI for review works well exactly because it limits the functionality available to users and enforces a particular commit model. If you don't do that, you get the code review mess that are Github/GitLab PRs/MRs - difficult to tell apart how commits relate to the change and how it progresses through review, because the entire branch history is free-form.
        kevincox 6y ago
        It's possible to allow users to have multiple commits but still show review between the submitted "tip" commits. If you want you don't even need to show the other commits in the UI.
      - detaro 6y ago
        One thing one has to get away from that one change request == one issue. Multiple small commits as separate change requests for one story are fine as long as they work standalone (which is generally a good idea, e.g. to enable bisecting)
  - js2 6y ago
    I much prefer the model of force-pushing your development branch to create change sets. It lets you more easily see how development evolves in response to feedback. And the final state of the branch which gets merged leaves all the in-progress work that no one cares about behind only in Gerrit. With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. Alternately, if you just keep adding commits, then the final branch that gets merged (unless you squash) has all the in-progress work which pollutes the repo's history. Gerrit also has a finer grained permission model, but I don't care as much about that. Gerrit definitely expects the user to understand how git works conceptually a bit more than Github/lab.
    - nemetroid 6y ago
      > With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. That's not quite true. Gitlab lets you compare any two "versions" of the force pushed branch.
      - js2 6y ago
        Thanks. I haven’t used gitlab. I assumed it worked the same as GitHub. That’s good to know.
        kevincox 6y ago
        Yup, GitLab works as expected here. It's always surprised me how quickly the old commit is garbage-collrcted when you force-push a branch on GitHub. It causes weird errors in CI runs and breaks viewing the old commits. Seriously I'll pay for those couple of KiB of space, just keep it around. (at least until the PR is closed)
    - 0x0 6y ago
      Gitlab DOES let you compare different versions of changesets in a merge request: https://docs.gitlab.com/ee/user/project/merge_requests/versions.html https://docs.gitlab.com/ee/user/project/merge_requests/versi...
    - 6y ago
- PieUser 6y ago
  This is sad. In my experience, GitHub is a much better code review system than GitLab merge requests. But it is different from what people are used to.
- dietrichepp 6y ago
  Probably because you got used to Critique at Google ;) I agree though. I think the most important thing in a code review system is inline comments in the diff itself, and that’s something you get from Gerrit, Phabricator (Differential), etc. It encourages people to discuss the particulars of of a diff. Merge approval can be made contingent on resolving minor issues within a diff. Diffs are also approved on a per-diff basis, and it’s less typical to merge a stack of diffs. I think the pull request / merge request makes sense with the “trusted lieutenants” development model that the Linux kernel uses, but for other projects you would be more likely to want a work flow where someone submits a single commit/diff and then someone approves it (after comments). When I review PRs on services like GitHub I very often think, “This should be several different reviews” and the discussion thread in a PR is often not a high-quality discussion. I don’t use GitLab as much but my experience is that it has the same problems. What I would love is to review a stack of commits and approve / make comments on the commits individually. (For those reading: Mondrian -> Rietveld -> Gettit, and also Mondrian -> Critique. Mondrian and Critique are internal tools at Google. Phabricator originated at Facebook which has a lot of ex-Google engineers on staff.)
  - nemetroid 6y ago
    I don't use Github much, but Gitlab allows for multiple threads in a merge request. These threads may reference diffs/commits, but can also be directed at the merge request in general. Each thread has to be explicitly resolved before merging.
  - eatthoselemons 6y ago
    Do you think that gitlab will ever add inline diff comments? I don't know if it would even be feasible to add to gitlab
    - e12e 6y ago
      More online than comments on the changes in the Mr? Like: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26540/diffs https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/2... (there's some old discussion on there, random example)
- huskyr 6y ago
  I guess you can get the hang of Gerrit, but i tried it out a couple of times (i occasionally do work on projects in the Wikimedia git repo) and is pretty evident that the interface is written by developers with little knowledge of user experience. Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now.
  - q3k 6y ago
    I really don't mind the Gerrit UX - it seems to be optimized for daily use by programmers, not for onboarding speed. That's a tradeoff I'm very much okay with.
    - badrequest 6y ago
      You're okay with the tool being difficult to use because you already know how to use it.
      - q3k 6y ago
        I'm okay with it being slightly more difficult to get started with, in return for higher productivity in the long run, yes. Right now, after spending a similar amount of time both with GitHub PRs (and Gitlab MRs) and Gerrit, I still find Gerrit much easier and faster to use.
        llimllib 6y ago
        I'm generally okay with that tradeoff too, but we tried it early on at our company and the juice was not worth the squeeze, at least in our case. Designers and even many developers found it essentially impossible to use and the developers who were reasonably comfortable with it spent way too much time assisting others in attempting to use it. (fwiw I found myself somewhere in the middle - I like the model and understood the ideas but also found it annoying to work with in practice)
        6y ago
- finnthehuman 6y ago
  It's depressing how git tooling has to squish out all the flexibility that makes git attractive in the name of being unsurprising to someone who doesn't understand git. I was excited to finally bring in git as we start ramping down on a legacy project onto something new. Then I started thinking about the developers that have never touched git and I need to support. I looked at the tools available and what workflows they dictate. Then there's the drive to do something similar to the rest of the company, autonomy only goes so far without a good reason. Fuck me. I'm going to pick GitLab and hate it.
- Entaroadun87 6y ago
  Why is it sad? They've identified a better experience for their target audience, new community devs, just that not perhaps for you haha.
- okhan 6y ago
  I had to use Gerrit in a previous job, and _hated_ it. The UX is abysmal. Some folks loved it though, especially engineers working mostly on the backend. People with more of a frontend focus couldn't get past the awful user experience.
  - alessioalex 6y ago
    Can confirm, it's extremely off-putting to say the least. Having previously used Github, Gitlab, Bitbucket I find Gerrit very unusual. I have to Google on how to do basic stuff.
A_No_Name_Mouse 6y ago
A compony moves their code repository to a different provider. Honest question: why is this news worthy? Am I missing something?
- melling 6y ago
  It helps to follow trends. For a while I thought Gitlab was part of GitHub. When I see enough news about something on HN, I look into it. I even did a little Rust tutorial recently. Buzz makes a difference
- vorpalhex 6y ago
  Wikimedia is very cautious in making changes because they take very seriously the values of sustainability and predictability. That they are moving from Gerrit to Gitlab is a blow against Gerrit and a boon for Gitlab (assuming it goes well).
  - A_No_Name_Mouse 6y ago
    Thanks. I'm not a developer so I guess it's relevant, just not for me.
  - zeitg3ist 6y ago
    I don’t know about Wikimedia being super cautious when adopting technologies... I host a MediaWiki instance and there’s been a lot of “not so cautious” tech decisions in the past. Jumping early on the HHVM train (which they eventually had to leave); adopting Lua for wiki modules; developing Parsoid as a Node service (now rewritten in PHP)... None of these was the “safe option”; in some cases it worked out well but in others it didn’t.
    - sayhar 6y ago
      What's wrong with HHVM? Honestly asking, I have no real context beyond knowing it is a FB invention
      - 6y ago
gravypod 6y ago
One thing stopping me from moving my company's code to gitlabs cloud offering is the storage sizes for repos being extremely small. I heard from a rep that this will change in November. I'm wondering if this purchase-more-storage change come relates to this?
- detaro 6y ago
  They're hosting Gitlab themselves.
- alex_reg 6y ago
  Wikimedia will self-host Gitlab. They can use whatever limits they want.
  - q3k 6y ago
    They are still very limited when it comes to functionality though - only the first column in https://about.gitlab.com/pricing/self-managed/feature-comparison/ https://about.gitlab.com/pricing/self-managed/feature-compar... , right?
    - Grimm1 6y ago
      My understanding is you can self host and pay a sub and get access to all the other features. I may be wrong.
      - boleary-gl 6y ago
        That's correct - with the GitLab Enterprise Edition you can self-host GitLab and get access to all of the features - both those from the Core open source version as well as our proprietary features.
      - mikey_p 6y ago
        Yes, but that's only if you self-host the Enterprise Edition which contains non-free code, not the Community Edition which only contains free code.
celeritascelery 6y ago
it was interesting to read their reasons for not using github, especially related to no control over bans or sanctions. Microsoft could pull the rug out from under them at any time if they got pressure from somebody like China.
- deleted 6y ago
  [deleted]
- simlevesque 6y ago
  I'm not sure how GitLab is a better option. China could pressure them too.
  - haolez 6y ago
    GitLab is open source and can be self-hosted by Wikimedia.
  - detaro 6y ago
    They're selfhosting.
    - simlevesque 6y ago
      Oh I get it now thank you. I had read only the outcome part.
    - addicted 6y ago
      Is this GitLab open source, or is it GitLab enterprise on the free plan? Because they are different products, even if the GitLab marketing pages make it appear as if they are the same.
      - simlevesque 6y ago
        Community Edition.
    - bastardoperator 6y ago
languagehacker 6y ago
In the past, I've found Gerrit to be reasonably good. Phabricator, on the other hand, not so much. Having worked with MediaWiki in the past on CRs, I think this will be a good move to modernize things for them. When faced with a similar task around the same time at Wikia (now Fandom), we chose GitHub while we were moving off of SVN. I'm glad we did at the time, even without all the additional features GitHub has. I understand why WMF didn't choose GitHub. Compared to their current stack, Gitlab is going to feel like a serious upgrade.
- nwah1 6y ago
  What features do you think Gitlab lacks compared to GitHub? I haven't used the CI/CD features of either, but PR/MR features seem comparable. Is it the advanced workflow stuff and CI/CD integration where GitHub is better? Bots? I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. But I would be a lot more worried about being locked-in to GitHub than Gitlab.
  - rock_hard 6y ago
    Gitlab is worse on almost every angle compared to Github It simply lacks the attention to detail...you can tell that Github walks the extra mile to get the UX right. We used Gitlab for a year and then migrated to Github...it’s a joy!
    - frenchyatwork 6y ago
      Having used both a fair bit, I don't know what you're talking about. If anything my experience has been the opposite. Gitlab had the second mover advantage on a few things, while Github's interface has some weird oddities that seem to stem from the fact that that's how they've always been.
    - cortesoft 6y ago
      Interesting... we used GHE for 7 years and have now switched to gitlab. Gitlab CI, container repos, and Kubernetes integration has been amazing.
paulus_magnus2 6y ago
^F gittorrent. It is like working in a big corporation. Eventually you will do / say something that won't be liked by a person in power / competitor and you will be cancelled. Community / public supported projects, also free speech are only safe from influence on community infrastructure. It's time to start decentralizing.
- JeremyNT 6y ago
  Canceled by whom? They are self-hosting their own instance of Gitlab CE. If Gitlab the company disappears tomorrow, they can fork the project and continue using it.
jancsika 6y ago
Anyone thinking of moving to their own Gitlab instance with Gitlab CE-- either stay on Github or prepare to waste your time dealing with user spam bots that pollute your site's search results. In other words-- if you want the common use case for a FOSS project: 1. publicly viewable main repository with publicly viewable issue tracker 2. requirement to log in to view all snippets, user profiles, perhaps even other repos as enforced by administrator settings (otherwise SEO bots will leverage these features to eat your search results) 3. anyone with an email can sign up to post issues to the main repo's issue tracker There is no combination of settings in Gitlab CE to achieve this. Any sane approach has to leave out step #2. That means that your Gitlab instance gets hammered with user spam from bots which then get indexed in Google search results for your site. Worse, Gitlab has no tools to make it easy to remove the user spam (and obviously no tools to prevent it from happening). Just run a public-facing Gitlab CE instance for a few days. Search for one of the spam snippets you collect, and you'll find results for all the FOSS projects out there running their own Gitlab instances. I've never seen any solutions offered by Gitlab for this, nor frankly any interest in the myriad bug reports about them addressing this at all. Edit: typo
- ben0x539 6y ago
  You'd think Wikimedia in particular has experience with the issue of spam bots polluting the site's search result.
- oconnor663 6y ago
  Is it possible to configure a robots.txt file to accomplish #2?
  - clscott 6y ago
    No, robots.txt is for well behaving bots like bing bot and google bot, not bots that will spam your forums (and Git repo apparently).
    - marcinzm 6y ago
      But if the issue is SEO bots then robots.txt would block the search engines thus meaning the spam content is of no importance (it's effectively private) and doesn't cause issues for the main sites SEO (nor help the spammers).
modernlearner 6y ago
I've been using Gitlab and honestly it's pretty awesome; using a mono-repo setup and everything just works. The integration of CI jobs is also excellent.
krelian 6y ago
I never checked out gitlab but the name always made it seem like a github copycat. If you want to differentiate your product why not choose a name that rings different to your competitor? And now I finally went and browsed some repositories and it's clear as that they were very much "inspired" but Github's design, it's practically a github clone, at least in that regard (although something is a bit off in the smoothness) Maybe one day I'll find myself in a similar position and see things differently but this blatant copying always seemed ridiculous to the point where I would feel ashamed to lead this type of strategy.
- Buttons840 6y ago
  People wanted a decentralized GitHub. That's why they built it like GitHub, except decentralized.
- boogies 6y ago
  If you think Gitlab’s a Github clone you must not have seen Gitea.
  - Wezl 6y ago
    I agree that Gitea looks a lot more like Github (but with a dark theme!), and I think this is a good thing. I also like Gitea because it doesn't have reCaptcha or other proprietary components, but it doesn't seem to have the advanced ('Enterprise') features that Gitlab does (I program as a hobby so I've never needed these). When Gitea has grown and is more accepted, I hope the Wikimedia Foundation will consider using it.
- globalproctd 6y ago
  You could not be farther from the truth. Gitlab is an improvement on Github in every way, they offer a suite of features that Github doesn't have that are only available through third party connections. Gitlab is not a Github clone.
- ganoushoreilly 6y ago
  Both are just fancy wrappers and tools built around GIT. It's not surprising that one looks like the other. Given historic exoduses from one, it's only logical the other would build a similar toolset with the intention of allow for easy migrations between platforms. While similar, the companies are different in the approaches, the platforms are different in their pricing (both having impacted the other which ultimately has helped consumers). Your argument would hold true of any word processor. I think it's an unfair assessment of two products targeting the same specific users.
lanevorockz 6y ago
Microsoft will slowly kill github
- throw_m239339 6y ago
  Depends. MS used to have its own code hosting service (Codeplex I believe), and it wasn't that bad, but Github was more "social". I think it's mostly a question of how independent Github will be under MS. Now to be fair, MS has good services. Azure is nice, and office 365 is pretty good.
  - syrrim 6y ago
    They might make money off if it, but I believe GP was referring to github's prominence as the home of so many free software projects.
zzzeek 6y ago
I think I have some relevant experience here. We host all of our projects on github: https://github.com/sqlalchemy/ https://github.com/sqlalchemy/ yet we also use gerrit! https://gerrit.sqlalchemy.org/ https://gerrit.sqlalchemy.org/ users send us pull requests, and they never have to deal with Gerrit ever. We use a custom integration, the source code to which is here: https://github.com/sqlalchemyorg/publishthing/tree/master/publishthing/apps/prtogerrit https://github.com/sqlalchemyorg/publishthing/tree/master/pu... and then we mostly bidirectional synchronization between Gerrit and Github pull requests (code changes can move freely from Github PR -> gerrit, comments and code review comments are posted bidirectionally, Gerrit status changes are synchronized into the PR - example: https://github.com/sqlalchemy/sqlalchemy/pull/5662 https://github.com/sqlalchemy/sqlalchemy/pull/5662 I continue to find Gerrit's code review to be vastly better than Githubs. Gitlab would take tremendous server resources to run internally and I like Github much better for the front-facing experience. I wrote about an earlier form of our integration here: https://techspot.zzzeek.org/2016/04/21/gerrit-is-awesome/ https://techspot.zzzeek.org/2016/04/21/gerrit-is-awesome/ to sum up: 1. your project benefits massively by being on Github 2. Gerrit is awesome (for me) 3. gitlab is not very appealing to me UX-wise and self-hosting wise 4. you can still use pull requests from outside users and use gerrit for code reviews.
- LockAndLol 6y ago
  > # Why > 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. and then further down > # FAQ > * Why is GitHub not considered? > - GitHub would be the first tool required to participate in the Wikimedia technical community that would be non Free Software and non self-hosted. > - GitHub also does not meet all of our needs; for example, GitHub grants little control of metadata, no influence over privacy policy/data retention, sanctions and bans, little control over backups and data integrity checks, and no long-term guaranteed access to underlying repository settings and configuration.
- augustohp 6y ago
Wezl 6y ago
I need clarification: is this Mediawiki or Wikimedia moving to gitlab? It seems the Wikimedia foundation is moving their code, so why is this on mediawiki.org?
- detaro 6y ago
  > so why is this on mediawiki.org? Probably because mediawiki is the main Wikimedia software project.
zdw 6y ago
I'd be interested in the CI aspects of this transition, which seem to be glossed over. The combination of Gerrit with Jenkins and Jenkins Job Builder blows everything else I've seen out of the water with how easy it is to make both per-patchset and post-integration changes in an infrastructure-as-code manner across multiple repos, once you get over the learning curve.
- brennen 6y ago
  We recently conducted an extensive evaluation of CI options[0], concluding at the time that GitLab could meet our needs but didn't make a whole lot of practical sense unless we also migrated to it for code review. Other considerations (Gerrit user experience and sustainability, onboarding costs, a de facto migration of many projects from our Gerrit instance to GitHub, etc.) led us to re-evaluate whether a migration for code review would make sense, and that's what the decision linked here addresses. I am on the team that maintains our existing CI system[1] (Zuul, Jenkins, JJB), though I mostly work on other things. While this system is certainly quite powerful, I would not personally describe it as easy. We have a lot of work in front of us in migrating it to GitLab, but so far I've found the experience there quite a bit more pleasant than grepping through JJB definitions and the like. At any rate, if you're interested in how all of this pans out, we will as ever be doing the work in a very public fashion. [0]. https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering... [1]. https://www.mediawiki.org/wiki/Continuous_integration https://www.mediawiki.org/wiki/Continuous_integration
  - zdw 6y ago
    To clarify, is your GitLab-based job system done with configuration-as-code and does it share definitions of jobs across repos? The solution we come up with in using Gerrit/Jenkins was to have a common test invocation (in our case `make test`) that glossed over all the details of a projects build process, and was expected to output test and coverage in specific formats Jenkins could consume (junit/xunit and cobertura). We have jobs that run `make test` no matter if the code is C, Go, Python, Javascript, etc. This also had the beneficial side effect of lowering the barrier to entry for someone working on any random project - make papers over all those toolchain differences.
slim 6y ago
is the deal with Wikimedia the reason gitlab blocked users from Iran ?
sitzkrieg 6y ago
why is this news
unixsheikh 6y ago
Google's non-free JavaScript recaptcha is an absolute showstopper! At least roll out a custom made solution of nothing else.
- brennen 6y ago
  We are not going to use reCAPTCHA.[0] [0]. https://www.mediawiki.org/wiki/GitLab_consultation/Discussion_summary#reCAPTCHA https://www.mediawiki.org/wiki/GitLab_consultation/Discussio...
dfalzone 6y ago
Would it make sense to implement a peer-to-peer protocol for sharing git repositories, similar to torrenting, with the goal of overcoming these kinds of issues?
pengaru 6y ago
I'll generally support using gitlab over github on principle, but have found gitlab to be basically useless without javascript enabled while github still kind of works at least for read-only visiting of shared github URLs. Whenever someone shares a gitlab URL with me, it's very rare I can make any use of it without enabling js, it's quite annoying.
- nichos 6y ago
  Of a simple page that works without JavaScript enabled is of interest to you, you might want to check out sourcehut.
  - pengaru 6y ago
    If I could compel everyone migrating to gitlab to instead use sourcehut, I would. Alas this isn't about my personal choice of git hosting, I already have my needs covered with a dedicated server.
mixologic 6y ago
"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." ... And nuclear power is a simple matter of splitting atoms.
vaccinator 6y ago
Since Microsoft is pro open-source now, they probably should move too.
gerdesj 6y ago
Things move so fast! git was initially developed on the back of a fag (cigarette) packet by Mr Torvalds and his mates for Linux code development. It seems to work quite well because we have a lot of gits these days. github or lab or gerrit? I don't have favourite but I did notice a lot more coloured lines with gerrit stuff and a feeling of bewilderment. However I also felt like the adults seemed to know what was going on. Let's see how this pans out. It'll probably be fine but I suspect we will lose something by creeping towards the "mainstream" and ignoring diversity. That sounds a bit odd for a tool designed for Linux 8)
chovyfu 6y ago
No more shithub.
zimbatm 6y ago
It's a shame that Gerrit doesn't get more TLC. Now that GitHub is owned by Microsoft, it would be a good way for Google to combat the ongoing centralization of open source. Fundamentally, the Gerrit changes model is superior than the pull-request model. I also really like how Gerrit stores all its information in git repos, comments, settings and everything else. The issue is everything that surrounds it. Talking from somebody who maintains an instance for a customer. The UI has all sorts of UX problems and takes a while to get into. The notification system is super noisy by default, we had to build a system on top and it's still not as good as GitHub's (which is also bad in its own respect).

889 points by input_sh 6y ago

q3k 6y ago

This is sad. In my experience, Gerrit is a much better code review system than Gitlab merge requests. But it is different from what people are used to.

epistasis 6y ago
What advantages do you see in Gerrit? Do they require a lot of experience in order to be realized?
- q3k 6y ago
  Clear mapping of change request == commit, allowing for easy building of multiple in flight change requests, rearranging them by using git rebase, updating with push to refs/for/master. Easy diffing between states of the CR (patch sets), so you can see what changes since the last round of comments, even if it spanned multiple updates. This is the feature I miss the most from other code review systems - be able to easily work on another commit that bases on one that I just sent out for review (even starting review on the new while the parent still hasn't finished being reviewed!), and rebasing my current change as the parent change gets reviewed/updated. Possibility to send out a PR for review using just a push (change message in commit, push to refs/for/master%r=foo). Snappy and compact code review experience (no space wasted for whitespace, avatars, pretty buttons). Full coverage with keyboard shortcuts. Powerful review rule system based in Prolog, allowing for things like code owners, experimental subdirectories without the need for review, etc.
  - dionian 6y ago
    > Clear mapping of change request == commit, was forced to use Gerrit by a client. I could never get the hang of this, I like to do frequent commits on short lived branches and using vanilla git. I never wanted any more features other than a nice UI to encourage people to review.
    - q3k 6y ago
      The nice UI for review works well exactly because it limits the functionality available to users and enforces a particular commit model. If you don't do that, you get the code review mess that are Github/GitLab PRs/MRs - difficult to tell apart how commits relate to the change and how it progresses through review, because the entire branch history is free-form.
      - kevincox 6y ago
        It's possible to allow users to have multiple commits but still show review between the submitted "tip" commits. If you want you don't even need to show the other commits in the UI.
    - detaro 6y ago
      One thing one has to get away from that one change request == one issue. Multiple small commits as separate change requests for one story are fine as long as they work standalone (which is generally a good idea, e.g. to enable bisecting)
- js2 6y ago
  I much prefer the model of force-pushing your development branch to create change sets. It lets you more easily see how development evolves in response to feedback. And the final state of the branch which gets merged leaves all the in-progress work that no one cares about behind only in Gerrit. With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. Alternately, if you just keep adding commits, then the final branch that gets merged (unless you squash) has all the in-progress work which pollutes the repo's history. Gerrit also has a finer grained permission model, but I don't care as much about that. Gerrit definitely expects the user to understand how git works conceptually a bit more than Github/lab.
  - nemetroid 6y ago
    > With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. That's not quite true. Gitlab lets you compare any two "versions" of the force pushed branch.
    - js2 6y ago
      Thanks. I haven’t used gitlab. I assumed it worked the same as GitHub. That’s good to know.
      - kevincox 6y ago
        Yup, GitLab works as expected here. It's always surprised me how quickly the old commit is garbage-collrcted when you force-push a branch on GitHub. It causes weird errors in CI runs and breaks viewing the old commits. Seriously I'll pay for those couple of KiB of space, just keep it around. (at least until the PR is closed)
  - 0x0 6y ago
    Gitlab DOES let you compare different versions of changesets in a merge request: https://docs.gitlab.com/ee/user/project/merge_requests/versions.html https://docs.gitlab.com/ee/user/project/merge_requests/versi...
  - 6y ago
PieUser 6y ago
This is sad. In my experience, GitHub is a much better code review system than GitLab merge requests. But it is different from what people are used to.
dietrichepp 6y ago
Probably because you got used to Critique at Google ;) I agree though. I think the most important thing in a code review system is inline comments in the diff itself, and that’s something you get from Gerrit, Phabricator (Differential), etc. It encourages people to discuss the particulars of of a diff. Merge approval can be made contingent on resolving minor issues within a diff. Diffs are also approved on a per-diff basis, and it’s less typical to merge a stack of diffs. I think the pull request / merge request makes sense with the “trusted lieutenants” development model that the Linux kernel uses, but for other projects you would be more likely to want a work flow where someone submits a single commit/diff and then someone approves it (after comments). When I review PRs on services like GitHub I very often think, “This should be several different reviews” and the discussion thread in a PR is often not a high-quality discussion. I don’t use GitLab as much but my experience is that it has the same problems. What I would love is to review a stack of commits and approve / make comments on the commits individually. (For those reading: Mondrian -> Rietveld -> Gettit, and also Mondrian -> Critique. Mondrian and Critique are internal tools at Google. Phabricator originated at Facebook which has a lot of ex-Google engineers on staff.)
- nemetroid 6y ago
  I don't use Github much, but Gitlab allows for multiple threads in a merge request. These threads may reference diffs/commits, but can also be directed at the merge request in general. Each thread has to be explicitly resolved before merging.
- eatthoselemons 6y ago
  Do you think that gitlab will ever add inline diff comments? I don't know if it would even be feasible to add to gitlab
  - e12e 6y ago
    More online than comments on the changes in the Mr? Like: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26540/diffs https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/2... (there's some old discussion on there, random example)
huskyr 6y ago
I guess you can get the hang of Gerrit, but i tried it out a couple of times (i occasionally do work on projects in the Wikimedia git repo) and is pretty evident that the interface is written by developers with little knowledge of user experience. Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now.
- q3k 6y ago
  I really don't mind the Gerrit UX - it seems to be optimized for daily use by programmers, not for onboarding speed. That's a tradeoff I'm very much okay with.
  - badrequest 6y ago
    You're okay with the tool being difficult to use because you already know how to use it.
    - q3k 6y ago
      I'm okay with it being slightly more difficult to get started with, in return for higher productivity in the long run, yes. Right now, after spending a similar amount of time both with GitHub PRs (and Gitlab MRs) and Gerrit, I still find Gerrit much easier and faster to use.
      - llimllib 6y ago
        I'm generally okay with that tradeoff too, but we tried it early on at our company and the juice was not worth the squeeze, at least in our case. Designers and even many developers found it essentially impossible to use and the developers who were reasonably comfortable with it spent way too much time assisting others in attempting to use it. (fwiw I found myself somewhere in the middle - I like the model and understood the ideas but also found it annoying to work with in practice)
        6y ago
finnthehuman 6y ago
It's depressing how git tooling has to squish out all the flexibility that makes git attractive in the name of being unsurprising to someone who doesn't understand git. I was excited to finally bring in git as we start ramping down on a legacy project onto something new. Then I started thinking about the developers that have never touched git and I need to support. I looked at the tools available and what workflows they dictate. Then there's the drive to do something similar to the rest of the company, autonomy only goes so far without a good reason. Fuck me. I'm going to pick GitLab and hate it.
Entaroadun87 6y ago
Why is it sad? They've identified a better experience for their target audience, new community devs, just that not perhaps for you haha.
okhan 6y ago
I had to use Gerrit in a previous job, and _hated_ it. The UX is abysmal. Some folks loved it though, especially engineers working mostly on the backend. People with more of a frontend focus couldn't get past the awful user experience.
- alessioalex 6y ago
  Can confirm, it's extremely off-putting to say the least. Having previously used Github, Gitlab, Bitbucket I find Gerrit very unusual. I have to Google on how to do basic stuff.

A_No_Name_Mouse 6y ago

A compony moves their code repository to a different provider. Honest question: why is this news worthy? Am I missing something?

melling 6y ago
It helps to follow trends. For a while I thought Gitlab was part of GitHub. When I see enough news about something on HN, I look into it. I even did a little Rust tutorial recently. Buzz makes a difference
vorpalhex 6y ago
Wikimedia is very cautious in making changes because they take very seriously the values of sustainability and predictability. That they are moving from Gerrit to Gitlab is a blow against Gerrit and a boon for Gitlab (assuming it goes well).
- A_No_Name_Mouse 6y ago
  Thanks. I'm not a developer so I guess it's relevant, just not for me.
- zeitg3ist 6y ago
  I don’t know about Wikimedia being super cautious when adopting technologies... I host a MediaWiki instance and there’s been a lot of “not so cautious” tech decisions in the past. Jumping early on the HHVM train (which they eventually had to leave); adopting Lua for wiki modules; developing Parsoid as a Node service (now rewritten in PHP)... None of these was the “safe option”; in some cases it worked out well but in others it didn’t.
  - sayhar 6y ago
    What's wrong with HHVM? Honestly asking, I have no real context beyond knowing it is a FB invention
    - 6y ago

gravypod 6y ago

One thing stopping me from moving my company's code to gitlabs cloud offering is the storage sizes for repos being extremely small. I heard from a rep that this will change in November. I'm wondering if this purchase-more-storage change come relates to this?

detaro 6y ago
They're hosting Gitlab themselves.
alex_reg 6y ago
Wikimedia will self-host Gitlab. They can use whatever limits they want.
- q3k 6y ago
  They are still very limited when it comes to functionality though - only the first column in https://about.gitlab.com/pricing/self-managed/feature-comparison/ https://about.gitlab.com/pricing/self-managed/feature-compar... , right?
  - Grimm1 6y ago
    My understanding is you can self host and pay a sub and get access to all the other features. I may be wrong.
    - boleary-gl 6y ago
      That's correct - with the GitLab Enterprise Edition you can self-host GitLab and get access to all of the features - both those from the Core open source version as well as our proprietary features.
    - mikey_p 6y ago
      Yes, but that's only if you self-host the Enterprise Edition which contains non-free code, not the Community Edition which only contains free code.

celeritascelery 6y ago

it was interesting to read their reasons for not using github, especially related to no control over bans or sanctions. Microsoft could pull the rug out from under them at any time if they got pressure from somebody like China.

deleted 6y ago
[deleted]
simlevesque 6y ago
I'm not sure how GitLab is a better option. China could pressure them too.
- haolez 6y ago
  GitLab is open source and can be self-hosted by Wikimedia.
- detaro 6y ago
  They're selfhosting.
  - simlevesque 6y ago
    Oh I get it now thank you. I had read only the outcome part.
  - addicted 6y ago
    Is this GitLab open source, or is it GitLab enterprise on the free plan? Because they are different products, even if the GitLab marketing pages make it appear as if they are the same.
    - simlevesque 6y ago
      Community Edition.
  - bastardoperator 6y ago

languagehacker 6y ago

In the past, I've found Gerrit to be reasonably good. Phabricator, on the other hand, not so much. Having worked with MediaWiki in the past on CRs, I think this will be a good move to modernize things for them. When faced with a similar task around the same time at Wikia (now Fandom), we chose GitHub while we were moving off of SVN. I'm glad we did at the time, even without all the additional features GitHub has. I understand why WMF didn't choose GitHub. Compared to their current stack, Gitlab is going to feel like a serious upgrade.

nwah1 6y ago
What features do you think Gitlab lacks compared to GitHub? I haven't used the CI/CD features of either, but PR/MR features seem comparable. Is it the advanced workflow stuff and CI/CD integration where GitHub is better? Bots? I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. But I would be a lot more worried about being locked-in to GitHub than Gitlab.
- rock_hard 6y ago
  Gitlab is worse on almost every angle compared to Github It simply lacks the attention to detail...you can tell that Github walks the extra mile to get the UX right. We used Gitlab for a year and then migrated to Github...it’s a joy!
  - frenchyatwork 6y ago
    Having used both a fair bit, I don't know what you're talking about. If anything my experience has been the opposite. Gitlab had the second mover advantage on a few things, while Github's interface has some weird oddities that seem to stem from the fact that that's how they've always been.
  - cortesoft 6y ago
    Interesting... we used GHE for 7 years and have now switched to gitlab. Gitlab CI, container repos, and Kubernetes integration has been amazing.

paulus_magnus2 6y ago

^F gittorrent. It is like working in a big corporation. Eventually you will do / say something that won't be liked by a person in power / competitor and you will be cancelled. Community / public supported projects, also free speech are only safe from influence on community infrastructure. It's time to start decentralizing.

JeremyNT 6y ago
Canceled by whom? They are self-hosting their own instance of Gitlab CE. If Gitlab the company disappears tomorrow, they can fork the project and continue using it.

jancsika 6y ago

Anyone thinking of moving to their own Gitlab instance with Gitlab CE-- either stay on Github or prepare to waste your time dealing with user spam bots that pollute your site's search results. In other words-- if you want the common use case for a FOSS project: 1. publicly viewable main repository with publicly viewable issue tracker 2. requirement to log in to view all snippets, user profiles, perhaps even other repos as enforced by administrator settings (otherwise SEO bots will leverage these features to eat your search results) 3. anyone with an email can sign up to post issues to the main repo's issue tracker There is no combination of settings in Gitlab CE to achieve this. Any sane approach has to leave out step #2. That means that your Gitlab instance gets hammered with user spam from bots which then get indexed in Google search results for your site. Worse, Gitlab has no tools to make it easy to remove the user spam (and obviously no tools to prevent it from happening). Just run a public-facing Gitlab CE instance for a few days. Search for one of the spam snippets you collect, and you'll find results for all the FOSS projects out there running their own Gitlab instances. I've never seen any solutions offered by Gitlab for this, nor frankly any interest in the myriad bug reports about them addressing this at all. Edit: typo

ben0x539 6y ago
You'd think Wikimedia in particular has experience with the issue of spam bots polluting the site's search result.
oconnor663 6y ago
Is it possible to configure a robots.txt file to accomplish #2?
- clscott 6y ago
  No, robots.txt is for well behaving bots like bing bot and google bot, not bots that will spam your forums (and Git repo apparently).
  - marcinzm 6y ago
    But if the issue is SEO bots then robots.txt would block the search engines thus meaning the spam content is of no importance (it's effectively private) and doesn't cause issues for the main sites SEO (nor help the spammers).

modernlearner 6y ago

I've been using Gitlab and honestly it's pretty awesome; using a mono-repo setup and everything just works. The integration of CI jobs is also excellent.

krelian 6y ago

I never checked out gitlab but the name always made it seem like a github copycat. If you want to differentiate your product why not choose a name that rings different to your competitor? And now I finally went and browsed some repositories and it's clear as that they were very much "inspired" but Github's design, it's practically a github clone, at least in that regard (although something is a bit off in the smoothness) Maybe one day I'll find myself in a similar position and see things differently but this blatant copying always seemed ridiculous to the point where I would feel ashamed to lead this type of strategy.

Buttons840 6y ago
People wanted a decentralized GitHub. That's why they built it like GitHub, except decentralized.
boogies 6y ago
If you think Gitlab’s a Github clone you must not have seen Gitea.
- Wezl 6y ago
  I agree that Gitea looks a lot more like Github (but with a dark theme!), and I think this is a good thing. I also like Gitea because it doesn't have reCaptcha or other proprietary components, but it doesn't seem to have the advanced ('Enterprise') features that Gitlab does (I program as a hobby so I've never needed these). When Gitea has grown and is more accepted, I hope the Wikimedia Foundation will consider using it.
globalproctd 6y ago
You could not be farther from the truth. Gitlab is an improvement on Github in every way, they offer a suite of features that Github doesn't have that are only available through third party connections. Gitlab is not a Github clone.
ganoushoreilly 6y ago
Both are just fancy wrappers and tools built around GIT. It's not surprising that one looks like the other. Given historic exoduses from one, it's only logical the other would build a similar toolset with the intention of allow for easy migrations between platforms. While similar, the companies are different in the approaches, the platforms are different in their pricing (both having impacted the other which ultimately has helped consumers). Your argument would hold true of any word processor. I think it's an unfair assessment of two products targeting the same specific users.

lanevorockz 6y ago

Microsoft will slowly kill github

throw_m239339 6y ago
Depends. MS used to have its own code hosting service (Codeplex I believe), and it wasn't that bad, but Github was more "social". I think it's mostly a question of how independent Github will be under MS. Now to be fair, MS has good services. Azure is nice, and office 365 is pretty good.
- syrrim 6y ago
  They might make money off if it, but I believe GP was referring to github's prominence as the home of so many free software projects.

zzzeek 6y ago

I think I have some relevant experience here. We host all of our projects on github: https://github.com/sqlalchemy/ https://github.com/sqlalchemy/ yet we also use gerrit! https://gerrit.sqlalchemy.org/ https://gerrit.sqlalchemy.org/ users send us pull requests, and they never have to deal with Gerrit ever. We use a custom integration, the source code to which is here: https://github.com/sqlalchemyorg/publishthing/tree/master/publishthing/apps/prtogerrit https://github.com/sqlalchemyorg/publishthing/tree/master/pu... and then we mostly bidirectional synchronization between Gerrit and Github pull requests (code changes can move freely from Github PR -> gerrit, comments and code review comments are posted bidirectionally, Gerrit status changes are synchronized into the PR - example: https://github.com/sqlalchemy/sqlalchemy/pull/5662 https://github.com/sqlalchemy/sqlalchemy/pull/5662 I continue to find Gerrit's code review to be vastly better than Githubs. Gitlab would take tremendous server resources to run internally and I like Github much better for the front-facing experience. I wrote about an earlier form of our integration here: https://techspot.zzzeek.org/2016/04/21/gerrit-is-awesome/ https://techspot.zzzeek.org/2016/04/21/gerrit-is-awesome/ to sum up: 1. your project benefits massively by being on Github 2. Gerrit is awesome (for me) 3. gitlab is not very appealing to me UX-wise and self-hosting wise 4. you can still use pull requests from outside users and use gerrit for code reviews.

LockAndLol 6y ago
> # Why > 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. and then further down > # FAQ > * Why is GitHub not considered? > - GitHub would be the first tool required to participate in the Wikimedia technical community that would be non Free Software and non self-hosted. > - GitHub also does not meet all of our needs; for example, GitHub grants little control of metadata, no influence over privacy policy/data retention, sanctions and bans, little control over backups and data integrity checks, and no long-term guaranteed access to underlying repository settings and configuration.
augustohp 6y ago

Wezl 6y ago

I need clarification: is this Mediawiki or Wikimedia moving to gitlab? It seems the Wikimedia foundation is moving their code, so why is this on mediawiki.org?

detaro 6y ago
> so why is this on mediawiki.org? Probably because mediawiki is the main Wikimedia software project.

zdw 6y ago

I'd be interested in the CI aspects of this transition, which seem to be glossed over. The combination of Gerrit with Jenkins and Jenkins Job Builder blows everything else I've seen out of the water with how easy it is to make both per-patchset and post-integration changes in an infrastructure-as-code manner across multiple repos, once you get over the learning curve.

brennen 6y ago
We recently conducted an extensive evaluation of CI options[0], concluding at the time that GitLab could meet our needs but didn't make a whole lot of practical sense unless we also migrated to it for code review. Other considerations (Gerrit user experience and sustainability, onboarding costs, a de facto migration of many projects from our Gerrit instance to GitHub, etc.) led us to re-evaluate whether a migration for code review would make sense, and that's what the decision linked here addresses. I am on the team that maintains our existing CI system[1] (Zuul, Jenkins, JJB), though I mostly work on other things. While this system is certainly quite powerful, I would not personally describe it as easy. We have a lot of work in front of us in migrating it to GitLab, but so far I've found the experience there quite a bit more pleasant than grepping through JJB definitions and the like. At any rate, if you're interested in how all of this pans out, we will as ever be doing the work in a very public fashion. [0]. https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering... [1]. https://www.mediawiki.org/wiki/Continuous_integration https://www.mediawiki.org/wiki/Continuous_integration
- zdw 6y ago
  To clarify, is your GitLab-based job system done with configuration-as-code and does it share definitions of jobs across repos? The solution we come up with in using Gerrit/Jenkins was to have a common test invocation (in our case `make test`) that glossed over all the details of a projects build process, and was expected to output test and coverage in specific formats Jenkins could consume (junit/xunit and cobertura). We have jobs that run `make test` no matter if the code is C, Go, Python, Javascript, etc. This also had the beneficial side effect of lowering the barrier to entry for someone working on any random project - make papers over all those toolchain differences.

slim 6y ago

is the deal with Wikimedia the reason gitlab blocked users from Iran ?

sitzkrieg 6y ago

why is this news

unixsheikh 6y ago

Google's non-free JavaScript recaptcha is an absolute showstopper! At least roll out a custom made solution of nothing else.

brennen 6y ago
We are not going to use reCAPTCHA.[0] [0]. https://www.mediawiki.org/wiki/GitLab_consultation/Discussion_summary#reCAPTCHA https://www.mediawiki.org/wiki/GitLab_consultation/Discussio...

dfalzone 6y ago

Would it make sense to implement a peer-to-peer protocol for sharing git repositories, similar to torrenting, with the goal of overcoming these kinds of issues?

pengaru 6y ago

I'll generally support using gitlab over github on principle, but have found gitlab to be basically useless without javascript enabled while github still kind of works at least for read-only visiting of shared github URLs. Whenever someone shares a gitlab URL with me, it's very rare I can make any use of it without enabling js, it's quite annoying.

nichos 6y ago
Of a simple page that works without JavaScript enabled is of interest to you, you might want to check out sourcehut.
- pengaru 6y ago
  If I could compel everyone migrating to gitlab to instead use sourcehut, I would. Alas this isn't about my personal choice of git hosting, I already have my needs covered with a dedicated server.

mixologic 6y ago

"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." ... And nuclear power is a simple matter of splitting atoms.

vaccinator 6y ago

Since Microsoft is pro open-source now, they probably should move too.

gerdesj 6y ago

Things move so fast! git was initially developed on the back of a fag (cigarette) packet by Mr Torvalds and his mates for Linux code development. It seems to work quite well because we have a lot of gits these days. github or lab or gerrit? I don't have favourite but I did notice a lot more coloured lines with gerrit stuff and a feeling of bewilderment. However I also felt like the adults seemed to know what was going on. Let's see how this pans out. It'll probably be fine but I suspect we will lose something by creeping towards the "mainstream" and ignoring diversity. That sounds a bit odd for a tool designed for Linux 8)

chovyfu 6y ago

No more shithub.

zimbatm 6y ago

It's a shame that Gerrit doesn't get more TLC. Now that GitHub is owned by Microsoft, it would be a good way for Google to combat the ongoing centralization of open source. Fundamentally, the Gerrit changes model is superior than the pull-request model. I also really like how Gerrit stores all its information in git repos, comments, settings and everything else. The issue is everything that surrounds it. Talking from somebody who maintains an instance for a customer. The UI has all sorts of UX problems and takes a while to get into. The notification system is super noisy by default, we had to build a system on top and it's still not as good as GitHub's (which is also bad in its own respect).