14 ms·

Debian and GNOME announce plans to migrate communities to GitLab

326 points by l2dy 9y ago

Dunedan 9y ago
I can't help to think that Gitlab is more and more eating Github's lunch. I wonder why we see so little from Github to get out of that situation.
- FBISurveillance 9y ago
  While I'm glad to see competition gearing up, I don't think GitHub and GitLab are in the same ballpark yet. While I'm a big fan of their team and culture approach, we yet to see better/respected GitLab.com SLA guarantees — it still feels like they're doing too much "testing on production".
  - zaarn 9y ago
    "testing in production" indeed. One of my repos has been stuck in limbo for over 2 months now after I attempted to migrate it to a group namespace from my own profile. Though I generally do like GitLab and favor Github alternatives over Github as I see it as a single point of failure for the FOSS community at this point.
    - YorickPeterse 9y ago
      > "testing in production" indeed. One of my repos has been stuck in limbo for over 2 months now > after I attempted to migrate it to a group namespace from my own profile. Have you created an issue for this on https://gitlab.com/gitlab-com/support-forum/issues https://gitlab.com/gitlab-com/support-forum/issues?
      - zaarn 9y ago
        Yes I have, there was no response to it and it was recently closed, I believe.
        connorshea 9y ago
        Could you link the issue so we can look into it?
        tscs37 9y ago
        Hi, I'm not OP but I've got myself into basically the same problem; https://gitlab.com/gitlab-com/support-forum/issues/2291 https://gitlab.com/gitlab-com/support-forum/issues/2291 I tried some various solutions via CURL to get the repository unstuck (basically rewriting the URL the request is sent to since the project settings page was pointing at the wrong repo) and it basically reports an empty repo on the target (which doesn't show up for me on my profile) and a 404 on the original (which does show up on my profile)
  - kogepathic 9y ago
    > While I'm a big fan of their team and culture approach, we yet to see better/respected GitLab.com SLA guarantees — it still feels like they're doing too much "testing on production". Agreed. However, if you need more reliability than gitlab.com it's not difficult to host GitLab yourself in a VM or on bare metal. Many companies already have their own physical servers in a DC (either colocated or leasing). Hopefully the people managing these servers know what they're doing and can give the developers a good SLA. Although some additional work on file/DB syncing would be necessary to have a hot spare.
    - bayindirh 9y ago
      GitLab on hosted hardware works great. I maintain two different instances. One of them automatically updates itself, and it just works.
    - rtpg 9y ago
      Or you can pay a nominal fee to GitHub and not have to manage anything... I like that Gitlab exists but I am willing to pay a lot of money to not have to manage yet another server
    - jrochkind1 9y ago
      Most non-huge companies are unlikely to be able provide _more_ reliability from a self-hosted installation than a cloud hosted installation. I suspect this is true of gitlab, but if it's not, it would speak negatively to gitlab's ability to provide a reliable service. Certainly while github is occasionally down or misbehaving, there's no way any enterprise I've worked at could self-host with as much reliability as github.
  - edjboston 9y ago
    Gitlabber here. We have a plan to address this and are kicking off our move to GCP shortly. Our top-level engineering department goal is to make gitlab.com ready for mission critical workloads and are targeting industry standard SLA's (e.g. three 9's). You can see our proposed architecture here if you're curious: https://about.gitlab.com/handbook/infrastructure/production-architecture/#infra-proposed-cloud-native https://about.gitlab.com/handbook/infrastructure/production-...
- lukaslalinsky 9y ago
  GitLab being open source and easy to run on your own hardware is a huge "selling" point. I don't think it's helping their income much, but it's growing the community of users and the money will probably come later. It's very hard for GitHub to compete with that. GitHub could introduce CI and other things that GitLab has, but it would be just one extra feature you have to pay for.
  - knocte 9y ago
    > I don't think it's helping their income much Being opensource is not normally an aspect that helps the income, actually the other way around. Opensource is the argument that wins for the customers that appreciate lack of vendor-lock-in.
    - globuous 9y ago
      I'd argue otherwise, but have no source to support my claims. Maybe someone can help. Here's my 2 cents: By being open source and allowing people to run it on their own servers, they can potentially convert a massive amount of people to their platform that otherwise wouldn't make the switch. Now the next time these people don't want to run gitlab on their own servers for whatever reason, they'll use their service. And pay for it. because they know the tools, the logic, the UI etc. The reason I'm arguing for this is because that's exactly what's happening with me. I'm a very happy github user, but I might need to run something similar on my own servers. If I do, I'll host a gitlab. And then, for my other projects where i don't need to run my own instance, I'll probably just use their webplatform. Because it takes me less time to navigate it now that I've run it. So i can see myself paying for gitlab some day because they've open sourced it and got me 'hooked' on their product as a result.
- grabcocque 9y ago
  Classic innovator’s dilemma. Their first mover advantage has made them complacent.
  - icebraining 9y ago
    I don't see why Github would have to cannibalize their own product to compete with Gitlab..
- akerro 9y ago
  Because github still has 99% of that market. Just look at how many repositories opened by Google, Facebook, Apple, Microsoft, NSA, GCHQ and 100s of others big players are on Github and how many on Gitlab.
  - syshum 9y ago
    Yes but how many of those are just mirrors and sources for non-contributors to find the code. See Linux Kernel as an example, the Kernel is mirrored on GitHub but none of the actual development takes place there.
    - akerro 9y ago
      I don't think it's about mirror of source code being there, I think it's more about a community of people and developers being able to report issues there. Eg. steam client is not opensource, but it has github repo where we report distro/Xorg/Wayland/libs related issues, and they often respond.
  - dordoka 9y ago
    That is true. But I reckon those big players just said "let's go with the flow and move some stuff to Github, good from the marketing point of view, etc". My point being that is just a trend. If Github is not careful, that trend can change anytime. Debian and GNOME are well known, big open source projects. This helps them a lot and pushes that trend a wee tiny bit in Gitlab's side.
  - sytse 9y ago
    Some of these use GitHub for their open source work but mostly GitLab for their closed source work.
  - dalore 9y ago
    People/companies go to GitHub to be social. It's the Facebook of computer code. That's why all the big players are there, so they can share/market themselves. It's also where a lot of programmers put their code so they can show it for interviews. That's why there are so many public repositories there.
- pizza234 9y ago
  It's not so easy. Which lunch are you talking about? Self-hosted or hosted? I don't think GL will ever have anything much in the hosted sector, for two main reasons: 1. GH's infrastructure is far ahead of GL, and 2. the social factor also affects companies that have private repositories, but also public ones - it wouldn't make sense to only move the private repositories to save money When we think about the self-hosted, then it's possible, but I'm not sure if that would significantly affect GH, which has a different business model.
  - regularfry 9y ago
    The way I see it going is that many, many large companies will have a bunch of teams on GitHub (with good reason), with both public and private repos. They will also have a bunch of teams on GitLab instances that have been wildcatted into existence, possibly before GitHub had decent inroads, but more probably so the code doesn't leave the firewall. At some point, a Boss who may or may not have Pointy Hair will look at the bill for GitHub, and the bill for the GitLab infrastructure, and say "Why am I paying for both?" At that point, the teams with code that can't leave the firewall have the trump card, and private repos on GitHub have to move off. It's not the money itself that makes the argument, it's paying twice for the same thing.
    - icebraining 9y ago
      Github does have a self-hosted version (Github Enterprise). Not open source, though.
    - pizza234 9y ago
      This is very speculative. Moving a significant part of the infrastructure is no joke, and requires extremely pressuring reasons. Licensing of course is one of those, but it's not necessarily the general case. When it comes to GL vs. GH, right now, speed is also a factor - try to fork a large project on GH and on GL; the last time I did, I was worried that I triggered a bug on GL, given how long it was taking. I speculate GL will have significant hurdles, since they work in the cloud (GH is on metal, and the reason a lead engineer gave me is speed), and they may have troubles scaling while containing expenses. I also doubt that there are so many companies with large projects on GH and small, "wildcat" projects on GL - GH dwarfs GL for hosted services. If and when mass migrations will be a concern, GH will surely have the tooling ready. Pointy hairs are not really relevant, since they may take any decision (even the opposite) for any whim.
- romanovcode 9y ago
  Can't see this happen until they fix their unintuitive UI and general slowlness of application. Other then that GitLab is amazing.
  - sytse 9y ago
    Have you tried our new UI in GitLab 10? We're not done yet making GitLab faster but it is getting better quickly. Last big thing we're working on are merge requests with hundreds of comments. Should come out on a few months.
    - ZenoArrow 9y ago
      I'm not sure what UI changes are in GitLab 10 but something that seems a little off for me is that when you're on a repo homepage, there can be quite a bit of scrolling before you get to the readme. For example: https://gitlab.com/gitlab-org/gitlab-ce/ https://gitlab.com/gitlab-org/gitlab-ce/ Perhaps this is by design, to emphasise the code rather than the description of the code, but in my opinion the repo homepage is mostly for those new to the code to start becoming acquainted with it (other pages are more focused on the needs of regular contributors, as they should be), so it makes sense (to me at least) to make the readme more prominent. I'm not going to suggest how to change it, as it's a decision that should be driven by the UI design team, but just flagging it as something to consider.
- jameskegel 9y ago
  Conversely github has never deleted my work and sidelined me for a day by making foolish mistakes
mathw 9y ago
I don't actually understand this. Are they referring to the agreements for contributing to GitLab itself, or for contributing to things hosted on GitLab, which surely have nothing to do with the hosting at all?
- jlgaddis 9y ago
  Yeah, I'm not sure what they mean by "migrate their communities". I'm not exactly real clear on "... and open source projects" either. Debian used to use Alioth [0] pretty extensively. Maybe they're getting rid of that and moving everything that was on there to GitLab. I get that this is a press release but it could be a bit more informative, IMO. [0]: https://wiki.debian.org/Alioth https://wiki.debian.org/Alioth
  - magpi3 9y ago
    I follow the debian devel list and yes they are moving away from alioth
  - tribaal 9y ago
    That's exactly what the link you pasted says - Debian is closing Alioth and migrate to using gitlab. No automatic migration is planned - you need to migrate the repos you are responsible for yourself.
  - jepler 9y ago
    The Debian project has been investigating several alternatives to Alioth's version control functionality. I have not 100% kept up on the discussion, but I think gitlab is either selected for sure or is a leading candidate. https://wiki.debian.org/Alioth/GitNext https://wiki.debian.org/Alioth/GitNext Even if they adopt gitlab for version control and pull requests, it's a very misleading headline that the "debian community" will be migrated to gitlab.
  - absoluteHNnoob 9y ago
    From Debian News (https://www.debian.org/News/weekly/ https://www.debian.org/News/weekly/): yes and it is going to be named Salsa (https://wiki.debian.org/Salsa https://wiki.debian.org/Salsa).
glutamate 9y ago
> GitLab, a software product used by 2/3 of all enterprises, ... This claim is false. The linked survey shows that GitLab has a 2/3 market share in self-hosted Git providers. Not every enterprise self-hosts a git repository.
- jlgaddis 9y ago
  Why let the truth get in the way of a good press release!? /s
  - Cthulhu_ 9y ago
    You're saying it's a falsehood and Nicole Plati, our media contact, gave alternative facts to that.
    - jlgaddis 9y ago
      There's a very big difference between "2/3 of all enterprises" (press release) and "a 2/3 market share in self-hosted Git providers" (glutamate, above). I've been a fan of GitLab's for quite a while (mostly due to your transparency; I just created an account a few weeks ago to try it out) but -- unless you are claiming that GitLab is being used by two-thirds of "all enterprises" -- this is very misleading, IMO.
      - notyourday 9y ago
        > There's a very big difference between "2/3 of all enterprises" (press release) and "a 2/3 market share in self-hosted Git providers" (glutamate, above). And even that is a total pulled out of the ass claim. At most it could be "who responded to our survey"
        Karunamon 9y ago
        It would take a lot less than 2/3 to have a representative sample, fwiw
      - 9y ago
akavel 9y ago
The rationale analysis they published via the linked article is interesting: https://docs.google.com/document/d/1zpjDzL7yhGBZz3_7jCjWLfRQ1Jryg1mlIVmG8y6B1_Q/edit https://docs.google.com/document/d/1zpjDzL7yhGBZz3_7jCjWLfRQ...
- deleted 9y ago
  [deleted]
jhasse 9y ago
GNOME already started, check out https://gitlab.gnome.org/GNOME https://gitlab.gnome.org/GNOME
- connorshea 9y ago
  Their infrastructure tracker has a lot of interesting info about the move[0]. You can also read through the development mailing list, it has a lot of discussion about the GitLab migration. At GitLab we're tracking the blocking issues they've brought up in this issue[2]. [0]: https://gitlab.gnome.org/GNOME/Infrastructure/issues https://gitlab.gnome.org/GNOME/Infrastructure/issues [1]: https://mail.gnome.org/archives/desktop-devel-list/ https://mail.gnome.org/archives/desktop-devel-list/ [2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/35287 https://gitlab.com/gitlab-org/gitlab-ce/issues/35287
jwildeboer 9y ago
They claim that Fedora requires a CLA. Which is simply not true. Fedora was one of the first projects to completely remove the need for a CLA. Seven(!) years ago. See https://opensource.com/law/10/6/new-contributor-agreement-fedora https://opensource.com/law/10/6/new-contributor-agreement-fe...
- sytse 9y ago
  Fedora requires an FPCA. In the comments below https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-license/#comment-3595989527 https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-l... we say the following about that: "While FPCA may not be a typical CLA with regard to rights and restrictions, this is not the only factor we looked into. We also were looking into whether there were terms in general, other than commonly used open source terms. Our analysis took into account that non-legal users do not always understand the nuances of legal language and can be deterred by any CLA, restrictive or not, if they do not understand the terms."
  - jwildeboer 9y ago
    I understand your position. But it hurts me a bit to see all of the hard work we put into replacing the Apache style CLA with the FPCA and our messaging around it to make sure we explain it in transparent ways being reduced to "doesn't really matter, it's still just a CLA if you're not an expert" :(
    - sytse 9y ago
      Mmm, I'm sorry to hear that. I agree that between CLA's there can be vast differences in the terms. We did not intent to detail those differences in our blog post. BTW Have you considered changing it to a DCO?
      - richardfontana 9y ago
        I've casually suggested this to some people involved in Fedora. FWIW I think it would be a good idea, and I think at this point the retention of the FPCA by Fedora is mostly a matter of inertia. But I share jwildeboer's sentiment, having been directly involved in the drafting of the FPCA to replace the old Fedora CLA. If one looks at the FPCA in historical context, it may be clearer that it is intended as an "un-CLA". One could argue that the DCO is a type of CLA. I know some people who call the DCO a contributor agreement, at least, and if it is a contributor agreement, it is one that refers to licensing of what's being contributed. Anyway, kudos to Gitlab for switching to the DCO!
bobajeff 9y ago
I remember reading awhile back that email was better suited than GitHub for large projects (eg. Linux). Wouldn't that still be the case with GitLab?
- tremon 9y ago
  Probably this link: http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel... ? In that case, yes, that applies to GitLab too. The main problem is how GitHub and GitLab manage subprojects: GitLab forks are strictly hierarchical in how they manage pull requests and contributions (you can only submit patches from your repo to the single repo that you forked from). But that may not be an issue for per-package repositories like Debian has on alioth. Debian does not have a monotree like the Linux kernel, every (source) package is a standalone project so the same objection does not apply here.
  - ramosmd 9y ago
    For how GitLab deals with forks, this blog post may offer some insights: https://about.gitlab.com/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/ https://about.gitlab.com/2016/12/01/how-to-keep-your-fork-up... This doc may also help: https://docs.gitlab.com/ee/workflow/repository_mirroring.html https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...
  - DouweM 9y ago
    Note that "you can only submit patches from your repo to the single repo that you forked from" is no longer true for GitLab starting with 10.1 (released October 22, see https://about.gitlab.com/2017/10/22/gitlab-10-1-released/#merge-requests-across-forks https://about.gitlab.com/2017/10/22/gitlab-10-1-released/#me...), and hasn't been true for GitHub for a while (perhaps forever).
sytse 9y ago
Previously discussed the blog post https://news.ycombinator.com/item?id=15602564 https://news.ycombinator.com/item?id=15602564
WD-42 9y ago
As someone who has attempted to contribute to the GNOME project, this makes me super happy. The current process is archaic: attaching patch files to weird bug trackers and then sorta just waiting for someone to get back to you... A proper pull request system with code review would lower the barrier of entry for contributions to these projects significantly.
- therealmarv 9y ago
  I don't even know how to do that although I use git every day ^^
  - WD-42 9y ago
    It's not hard to create a patch from a commit, but it's very awkward and doesn't fit the "flow" I've become accustomed to while using git.
- owninghome 9y ago
  Yup, I can’t count how many times I kept bugfixes, improvements, or tweaks to myself because the submission process is too complicated and user hostile. This is honestly a problem with any submission process involving patch files. I’ve submitted a few via mailing list and I can’t express how much I dread seeing source controled this way.
  - mdaniel 9y ago
    For sure, and it's arguably worse when they claim "patches welcome" and then the PR sits for years without so much as a "please wait." Insult to injury when the PR is just a typo fix, or cleaning up a blatant lie in the documentation.
- johannes1234321 9y ago
  Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up. But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.
jwilk 9y ago
The title says "Debian and GNOME announce plans to migrate communities to GitLab" but unless I'm missing something, there's nothing in the article about this supposed migration.
- marenkay 9y ago
  > Debian and GNOME both plan to migrate their communities and open source projects to GitLab 1st paragraph.
deleted 9y ago
[deleted]
shmerl 9y ago
I'd really appreciate Web based way of Debian bug reporting. It doens't need to replace the current one, I suppose they can make some Gitlub plugin for e-mail method.
- teddyh 9y ago
  GitLab is not replacing DebBugs, it is replacing Alioth.
  - shmerl 9y ago
    It could compliment it, not replace may be.
ericfrederich 9y ago
From where? Article doesn't mention where they're migrating from.
- passivepinetree 9y ago
  From the email patching system. It's a tried-and-true model, but it tends to be unfriendly to new contributors.
jwilk 9y ago
GitLab is unusable without JavaScript enabled. It's disappointing to see free software projects even consider adopting it.
- jancsika 9y ago
  Just navigated my own running instance of gitlab-omnibus with Firefox's javascript.enabled set to false. It looks fine to me-- I can navigate, view the issues, and presumably post comments. What is it that you are claiming is unusable without JavaScript?
  - jwilk 9y ago
    I can't register, because the "Register" tab on https://gitlab.gnome.org/users/sign_in https://gitlab.gnome.org/users/sign_in doesn't work. Issues (such as https://gitlab.gnome.org/GNOME/json-glib/issues/26 https://gitlab.gnome.org/GNOME/json-glib/issues/26) show the initial message, but not the comments. (I'm sure that's just tip of the iceberg.)
0xFFC 9y ago
Although unrelated, but with recent migration to Meson in Gnome ecosystem I really want to contribute to their code base in my spare time. Autotools was just like hell to work on!
MrFurious 9y ago
i guess that debian and gnome are preparing her nuclear reactors for execute gitlab, :P
Ruud-v-A 9y ago
I was under the impression that Debian is in the process of moving to Pagure [1]. The reasons mentioned in the LWN article are not invalidated by Gitlab's announcement of dropping the CLA. [1]: https://lwn.net/Articles/724986/ https://lwn.net/Articles/724986/
- connorshea 9y ago
  Based on the Debian Wiki, plans have since changed[0] (unless this page is outdated?). That LWN article is from June, the wiki article was last edited in September. My understanding from the mailing list is that they're planning on using GitLab, at least that's what I heard last. I could always be wrong. [0]: https://wiki.debian.org/Alioth#Deprecation_of_Alioth https://wiki.debian.org/Alioth#Deprecation_of_Alioth
  - vbernat 9y ago
    You are right. Part of discussion starts here: https://lists.debian.org/debian-devel/2017/10/msg00264.html https://lists.debian.org/debian-devel/2017/10/msg00264.html
ausjke 9y ago
An active gitea user here, gitlab is too heavy for my person self-hosting site, at the moment, github for social coding, gitea for personal repo, tried but not jumping on gitlab and do not see a need for that.
- marenkay 9y ago
  ... pair that with Drone and/or GoCD. Personally I avoid using GitLab for professional and private use as it is using Omnibus packaging and comes with a whole bunch of software that usually is neatly packaged by any Linux distribution.
jbverschoor 9y ago
Great news for GitLab!

326 points by l2dy 9y ago

I can't help to think that Gitlab is more and more eating Github's lunch. I wonder why we see so little from Github to get out of that situation.

FBISurveillance 9y ago
While I'm glad to see competition gearing up, I don't think GitHub and GitLab are in the same ballpark yet. While I'm a big fan of their team and culture approach, we yet to see better/respected GitLab.com SLA guarantees — it still feels like they're doing too much "testing on production".
- zaarn 9y ago
  "testing in production" indeed. One of my repos has been stuck in limbo for over 2 months now after I attempted to migrate it to a group namespace from my own profile. Though I generally do like GitLab and favor Github alternatives over Github as I see it as a single point of failure for the FOSS community at this point.
  - YorickPeterse 9y ago
    > "testing in production" indeed. One of my repos has been stuck in limbo for over 2 months now > after I attempted to migrate it to a group namespace from my own profile. Have you created an issue for this on https://gitlab.com/gitlab-com/support-forum/issues https://gitlab.com/gitlab-com/support-forum/issues?
    - zaarn 9y ago
      Yes I have, there was no response to it and it was recently closed, I believe.
      - connorshea 9y ago
        Could you link the issue so we can look into it?
        tscs37 9y ago
        Hi, I'm not OP but I've got myself into basically the same problem; https://gitlab.com/gitlab-com/support-forum/issues/2291 https://gitlab.com/gitlab-com/support-forum/issues/2291 I tried some various solutions via CURL to get the repository unstuck (basically rewriting the URL the request is sent to since the project settings page was pointing at the wrong repo) and it basically reports an empty repo on the target (which doesn't show up for me on my profile) and a 404 on the original (which does show up on my profile)
- kogepathic 9y ago
  > While I'm a big fan of their team and culture approach, we yet to see better/respected GitLab.com SLA guarantees — it still feels like they're doing too much "testing on production". Agreed. However, if you need more reliability than gitlab.com it's not difficult to host GitLab yourself in a VM or on bare metal. Many companies already have their own physical servers in a DC (either colocated or leasing). Hopefully the people managing these servers know what they're doing and can give the developers a good SLA. Although some additional work on file/DB syncing would be necessary to have a hot spare.
  - bayindirh 9y ago
    GitLab on hosted hardware works great. I maintain two different instances. One of them automatically updates itself, and it just works.
  - rtpg 9y ago
    Or you can pay a nominal fee to GitHub and not have to manage anything... I like that Gitlab exists but I am willing to pay a lot of money to not have to manage yet another server
  - jrochkind1 9y ago
    Most non-huge companies are unlikely to be able provide _more_ reliability from a self-hosted installation than a cloud hosted installation. I suspect this is true of gitlab, but if it's not, it would speak negatively to gitlab's ability to provide a reliable service. Certainly while github is occasionally down or misbehaving, there's no way any enterprise I've worked at could self-host with as much reliability as github.
- edjboston 9y ago
  Gitlabber here. We have a plan to address this and are kicking off our move to GCP shortly. Our top-level engineering department goal is to make gitlab.com ready for mission critical workloads and are targeting industry standard SLA's (e.g. three 9's). You can see our proposed architecture here if you're curious: https://about.gitlab.com/handbook/infrastructure/production-architecture/#infra-proposed-cloud-native https://about.gitlab.com/handbook/infrastructure/production-...
lukaslalinsky 9y ago
GitLab being open source and easy to run on your own hardware is a huge "selling" point. I don't think it's helping their income much, but it's growing the community of users and the money will probably come later. It's very hard for GitHub to compete with that. GitHub could introduce CI and other things that GitLab has, but it would be just one extra feature you have to pay for.
- knocte 9y ago
  > I don't think it's helping their income much Being opensource is not normally an aspect that helps the income, actually the other way around. Opensource is the argument that wins for the customers that appreciate lack of vendor-lock-in.
  - globuous 9y ago
    I'd argue otherwise, but have no source to support my claims. Maybe someone can help. Here's my 2 cents: By being open source and allowing people to run it on their own servers, they can potentially convert a massive amount of people to their platform that otherwise wouldn't make the switch. Now the next time these people don't want to run gitlab on their own servers for whatever reason, they'll use their service. And pay for it. because they know the tools, the logic, the UI etc. The reason I'm arguing for this is because that's exactly what's happening with me. I'm a very happy github user, but I might need to run something similar on my own servers. If I do, I'll host a gitlab. And then, for my other projects where i don't need to run my own instance, I'll probably just use their webplatform. Because it takes me less time to navigate it now that I've run it. So i can see myself paying for gitlab some day because they've open sourced it and got me 'hooked' on their product as a result.
grabcocque 9y ago
Classic innovator’s dilemma. Their first mover advantage has made them complacent.
- icebraining 9y ago
  I don't see why Github would have to cannibalize their own product to compete with Gitlab..
akerro 9y ago
Because github still has 99% of that market. Just look at how many repositories opened by Google, Facebook, Apple, Microsoft, NSA, GCHQ and 100s of others big players are on Github and how many on Gitlab.
- syshum 9y ago
  Yes but how many of those are just mirrors and sources for non-contributors to find the code. See Linux Kernel as an example, the Kernel is mirrored on GitHub but none of the actual development takes place there.
  - akerro 9y ago
    I don't think it's about mirror of source code being there, I think it's more about a community of people and developers being able to report issues there. Eg. steam client is not opensource, but it has github repo where we report distro/Xorg/Wayland/libs related issues, and they often respond.
- dordoka 9y ago
  That is true. But I reckon those big players just said "let's go with the flow and move some stuff to Github, good from the marketing point of view, etc". My point being that is just a trend. If Github is not careful, that trend can change anytime. Debian and GNOME are well known, big open source projects. This helps them a lot and pushes that trend a wee tiny bit in Gitlab's side.
- sytse 9y ago
  Some of these use GitHub for their open source work but mostly GitLab for their closed source work.
- dalore 9y ago
  People/companies go to GitHub to be social. It's the Facebook of computer code. That's why all the big players are there, so they can share/market themselves. It's also where a lot of programmers put their code so they can show it for interviews. That's why there are so many public repositories there.
pizza234 9y ago
It's not so easy. Which lunch are you talking about? Self-hosted or hosted? I don't think GL will ever have anything much in the hosted sector, for two main reasons: 1. GH's infrastructure is far ahead of GL, and 2. the social factor also affects companies that have private repositories, but also public ones - it wouldn't make sense to only move the private repositories to save money When we think about the self-hosted, then it's possible, but I'm not sure if that would significantly affect GH, which has a different business model.
- regularfry 9y ago
  The way I see it going is that many, many large companies will have a bunch of teams on GitHub (with good reason), with both public and private repos. They will also have a bunch of teams on GitLab instances that have been wildcatted into existence, possibly before GitHub had decent inroads, but more probably so the code doesn't leave the firewall. At some point, a Boss who may or may not have Pointy Hair will look at the bill for GitHub, and the bill for the GitLab infrastructure, and say "Why am I paying for both?" At that point, the teams with code that can't leave the firewall have the trump card, and private repos on GitHub have to move off. It's not the money itself that makes the argument, it's paying twice for the same thing.
  - icebraining 9y ago
    Github does have a self-hosted version (Github Enterprise). Not open source, though.
  - pizza234 9y ago
    This is very speculative. Moving a significant part of the infrastructure is no joke, and requires extremely pressuring reasons. Licensing of course is one of those, but it's not necessarily the general case. When it comes to GL vs. GH, right now, speed is also a factor - try to fork a large project on GH and on GL; the last time I did, I was worried that I triggered a bug on GL, given how long it was taking. I speculate GL will have significant hurdles, since they work in the cloud (GH is on metal, and the reason a lead engineer gave me is speed), and they may have troubles scaling while containing expenses. I also doubt that there are so many companies with large projects on GH and small, "wildcat" projects on GL - GH dwarfs GL for hosted services. If and when mass migrations will be a concern, GH will surely have the tooling ready. Pointy hairs are not really relevant, since they may take any decision (even the opposite) for any whim.
romanovcode 9y ago
Can't see this happen until they fix their unintuitive UI and general slowlness of application. Other then that GitLab is amazing.
- sytse 9y ago
  Have you tried our new UI in GitLab 10? We're not done yet making GitLab faster but it is getting better quickly. Last big thing we're working on are merge requests with hundreds of comments. Should come out on a few months.
  - ZenoArrow 9y ago
    I'm not sure what UI changes are in GitLab 10 but something that seems a little off for me is that when you're on a repo homepage, there can be quite a bit of scrolling before you get to the readme. For example: https://gitlab.com/gitlab-org/gitlab-ce/ https://gitlab.com/gitlab-org/gitlab-ce/ Perhaps this is by design, to emphasise the code rather than the description of the code, but in my opinion the repo homepage is mostly for those new to the code to start becoming acquainted with it (other pages are more focused on the needs of regular contributors, as they should be), so it makes sense (to me at least) to make the readme more prominent. I'm not going to suggest how to change it, as it's a decision that should be driven by the UI design team, but just flagging it as something to consider.
jameskegel 9y ago
Conversely github has never deleted my work and sidelined me for a day by making foolish mistakes

mathw 9y ago

I don't actually understand this. Are they referring to the agreements for contributing to GitLab itself, or for contributing to things hosted on GitLab, which surely have nothing to do with the hosting at all?

jlgaddis 9y ago
Yeah, I'm not sure what they mean by "migrate their communities". I'm not exactly real clear on "... and open source projects" either. Debian used to use Alioth [0] pretty extensively. Maybe they're getting rid of that and moving everything that was on there to GitLab. I get that this is a press release but it could be a bit more informative, IMO. [0]: https://wiki.debian.org/Alioth https://wiki.debian.org/Alioth
- magpi3 9y ago
  I follow the debian devel list and yes they are moving away from alioth
- tribaal 9y ago
  That's exactly what the link you pasted says - Debian is closing Alioth and migrate to using gitlab. No automatic migration is planned - you need to migrate the repos you are responsible for yourself.
- jepler 9y ago
  The Debian project has been investigating several alternatives to Alioth's version control functionality. I have not 100% kept up on the discussion, but I think gitlab is either selected for sure or is a leading candidate. https://wiki.debian.org/Alioth/GitNext https://wiki.debian.org/Alioth/GitNext Even if they adopt gitlab for version control and pull requests, it's a very misleading headline that the "debian community" will be migrated to gitlab.
- absoluteHNnoob 9y ago
  From Debian News (https://www.debian.org/News/weekly/ https://www.debian.org/News/weekly/): yes and it is going to be named Salsa (https://wiki.debian.org/Salsa https://wiki.debian.org/Salsa).

glutamate 9y ago

> GitLab, a software product used by 2/3 of all enterprises, ... This claim is false. The linked survey shows that GitLab has a 2/3 market share in self-hosted Git providers. Not every enterprise self-hosts a git repository.

jlgaddis 9y ago
Why let the truth get in the way of a good press release!? /s
- Cthulhu_ 9y ago
  You're saying it's a falsehood and Nicole Plati, our media contact, gave alternative facts to that.
  - jlgaddis 9y ago
    There's a very big difference between "2/3 of all enterprises" (press release) and "a 2/3 market share in self-hosted Git providers" (glutamate, above). I've been a fan of GitLab's for quite a while (mostly due to your transparency; I just created an account a few weeks ago to try it out) but -- unless you are claiming that GitLab is being used by two-thirds of "all enterprises" -- this is very misleading, IMO.
    - notyourday 9y ago
      > There's a very big difference between "2/3 of all enterprises" (press release) and "a 2/3 market share in self-hosted Git providers" (glutamate, above). And even that is a total pulled out of the ass claim. At most it could be "who responded to our survey"
      - Karunamon 9y ago
        It would take a lot less than 2/3 to have a representative sample, fwiw
    - 9y ago

akavel 9y ago

The rationale analysis they published via the linked article is interesting: https://docs.google.com/document/d/1zpjDzL7yhGBZz3_7jCjWLfRQ1Jryg1mlIVmG8y6B1_Q/edit https://docs.google.com/document/d/1zpjDzL7yhGBZz3_7jCjWLfRQ...

deleted 9y ago
[deleted]

jhasse 9y ago

GNOME already started, check out https://gitlab.gnome.org/GNOME https://gitlab.gnome.org/GNOME

connorshea 9y ago
Their infrastructure tracker has a lot of interesting info about the move[0]. You can also read through the development mailing list, it has a lot of discussion about the GitLab migration. At GitLab we're tracking the blocking issues they've brought up in this issue[2]. [0]: https://gitlab.gnome.org/GNOME/Infrastructure/issues https://gitlab.gnome.org/GNOME/Infrastructure/issues [1]: https://mail.gnome.org/archives/desktop-devel-list/ https://mail.gnome.org/archives/desktop-devel-list/ [2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/35287 https://gitlab.com/gitlab-org/gitlab-ce/issues/35287

jwildeboer 9y ago

They claim that Fedora requires a CLA. Which is simply not true. Fedora was one of the first projects to completely remove the need for a CLA. Seven(!) years ago. See https://opensource.com/law/10/6/new-contributor-agreement-fedora https://opensource.com/law/10/6/new-contributor-agreement-fe...

sytse 9y ago
Fedora requires an FPCA. In the comments below https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-license/#comment-3595989527 https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-l... we say the following about that: "While FPCA may not be a typical CLA with regard to rights and restrictions, this is not the only factor we looked into. We also were looking into whether there were terms in general, other than commonly used open source terms. Our analysis took into account that non-legal users do not always understand the nuances of legal language and can be deterred by any CLA, restrictive or not, if they do not understand the terms."
- jwildeboer 9y ago
  I understand your position. But it hurts me a bit to see all of the hard work we put into replacing the Apache style CLA with the FPCA and our messaging around it to make sure we explain it in transparent ways being reduced to "doesn't really matter, it's still just a CLA if you're not an expert" :(
  - sytse 9y ago
    Mmm, I'm sorry to hear that. I agree that between CLA's there can be vast differences in the terms. We did not intent to detail those differences in our blog post. BTW Have you considered changing it to a DCO?
    - richardfontana 9y ago
      I've casually suggested this to some people involved in Fedora. FWIW I think it would be a good idea, and I think at this point the retention of the FPCA by Fedora is mostly a matter of inertia. But I share jwildeboer's sentiment, having been directly involved in the drafting of the FPCA to replace the old Fedora CLA. If one looks at the FPCA in historical context, it may be clearer that it is intended as an "un-CLA". One could argue that the DCO is a type of CLA. I know some people who call the DCO a contributor agreement, at least, and if it is a contributor agreement, it is one that refers to licensing of what's being contributed. Anyway, kudos to Gitlab for switching to the DCO!

bobajeff 9y ago

I remember reading awhile back that email was better suited than GitHub for large projects (eg. Linux). Wouldn't that still be the case with GitLab?

tremon 9y ago
Probably this link: http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel... ? In that case, yes, that applies to GitLab too. The main problem is how GitHub and GitLab manage subprojects: GitLab forks are strictly hierarchical in how they manage pull requests and contributions (you can only submit patches from your repo to the single repo that you forked from). But that may not be an issue for per-package repositories like Debian has on alioth. Debian does not have a monotree like the Linux kernel, every (source) package is a standalone project so the same objection does not apply here.
- ramosmd 9y ago
  For how GitLab deals with forks, this blog post may offer some insights: https://about.gitlab.com/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/ https://about.gitlab.com/2016/12/01/how-to-keep-your-fork-up... This doc may also help: https://docs.gitlab.com/ee/workflow/repository_mirroring.html https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...
- DouweM 9y ago
  Note that "you can only submit patches from your repo to the single repo that you forked from" is no longer true for GitLab starting with 10.1 (released October 22, see https://about.gitlab.com/2017/10/22/gitlab-10-1-released/#merge-requests-across-forks https://about.gitlab.com/2017/10/22/gitlab-10-1-released/#me...), and hasn't been true for GitHub for a while (perhaps forever).

sytse 9y ago

Previously discussed the blog post https://news.ycombinator.com/item?id=15602564 https://news.ycombinator.com/item?id=15602564

WD-42 9y ago

As someone who has attempted to contribute to the GNOME project, this makes me super happy. The current process is archaic: attaching patch files to weird bug trackers and then sorta just waiting for someone to get back to you... A proper pull request system with code review would lower the barrier of entry for contributions to these projects significantly.

therealmarv 9y ago
I don't even know how to do that although I use git every day ^^
- WD-42 9y ago
  It's not hard to create a patch from a commit, but it's very awkward and doesn't fit the "flow" I've become accustomed to while using git.
owninghome 9y ago
Yup, I can’t count how many times I kept bugfixes, improvements, or tweaks to myself because the submission process is too complicated and user hostile. This is honestly a problem with any submission process involving patch files. I’ve submitted a few via mailing list and I can’t express how much I dread seeing source controled this way.
- mdaniel 9y ago
  For sure, and it's arguably worse when they claim "patches welcome" and then the PR sits for years without so much as a "please wait." Insult to injury when the PR is just a typo fix, or cleaning up a blatant lie in the documentation.
johannes1234321 9y ago
Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up. But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.

jwilk 9y ago

The title says "Debian and GNOME announce plans to migrate communities to GitLab" but unless I'm missing something, there's nothing in the article about this supposed migration.

marenkay 9y ago
> Debian and GNOME both plan to migrate their communities and open source projects to GitLab 1st paragraph.

deleted 9y ago

[deleted]

shmerl 9y ago

I'd really appreciate Web based way of Debian bug reporting. It doens't need to replace the current one, I suppose they can make some Gitlub plugin for e-mail method.

teddyh 9y ago
GitLab is not replacing DebBugs, it is replacing Alioth.
- shmerl 9y ago
  It could compliment it, not replace may be.

ericfrederich 9y ago

From where? Article doesn't mention where they're migrating from.

passivepinetree 9y ago
From the email patching system. It's a tried-and-true model, but it tends to be unfriendly to new contributors.

jwilk 9y ago

GitLab is unusable without JavaScript enabled. It's disappointing to see free software projects even consider adopting it.

jancsika 9y ago
Just navigated my own running instance of gitlab-omnibus with Firefox's javascript.enabled set to false. It looks fine to me-- I can navigate, view the issues, and presumably post comments. What is it that you are claiming is unusable without JavaScript?
- jwilk 9y ago
  I can't register, because the "Register" tab on https://gitlab.gnome.org/users/sign_in https://gitlab.gnome.org/users/sign_in doesn't work. Issues (such as https://gitlab.gnome.org/GNOME/json-glib/issues/26 https://gitlab.gnome.org/GNOME/json-glib/issues/26) show the initial message, but not the comments. (I'm sure that's just tip of the iceberg.)

0xFFC 9y ago

Although unrelated, but with recent migration to Meson in Gnome ecosystem I really want to contribute to their code base in my spare time. Autotools was just like hell to work on!

MrFurious 9y ago

i guess that debian and gnome are preparing her nuclear reactors for execute gitlab, :P

Ruud-v-A 9y ago

I was under the impression that Debian is in the process of moving to Pagure [1]. The reasons mentioned in the LWN article are not invalidated by Gitlab's announcement of dropping the CLA. [1]: https://lwn.net/Articles/724986/ https://lwn.net/Articles/724986/

connorshea 9y ago
Based on the Debian Wiki, plans have since changed[0] (unless this page is outdated?). That LWN article is from June, the wiki article was last edited in September. My understanding from the mailing list is that they're planning on using GitLab, at least that's what I heard last. I could always be wrong. [0]: https://wiki.debian.org/Alioth#Deprecation_of_Alioth https://wiki.debian.org/Alioth#Deprecation_of_Alioth
- vbernat 9y ago
  You are right. Part of discussion starts here: https://lists.debian.org/debian-devel/2017/10/msg00264.html https://lists.debian.org/debian-devel/2017/10/msg00264.html

ausjke 9y ago

An active gitea user here, gitlab is too heavy for my person self-hosting site, at the moment, github for social coding, gitea for personal repo, tried but not jumping on gitlab and do not see a need for that.

marenkay 9y ago
... pair that with Drone and/or GoCD. Personally I avoid using GitLab for professional and private use as it is using Omnibus packaging and comes with a whole bunch of software that usually is neatly packaged by any Linux distribution.

jbverschoor 9y ago

Great news for GitLab!