Live data from Hacker News

Debian and GNOME announce plans to migrate communities to GitLab

about.gitlab.com

71–80 of 164 posts

Re: Debian and GNOME announce plans to migrate communities to GitLab

#71
post #56

Earlier quoted context omitted.

We claim it based on the assumption that almost all very large companies (enterprise) host their own source code and they are switching to git. We have 2/3 market share with self hosted git as shown with two data points https://about.gitlab.com/is-it-any-good/#gitlab-has-23-marke... I'll consider adding the rationale to the page. We're seeing organizations adopt SaaS but the largest companies tend to be the last ones…

From bitrise link > We randomly selected 10,000 apps as a base "2/3 of all enterprises" can only be true if all enterprises are building apps on bitrise.

I do agree that the majority of Bitrise their population is not the enterprise at all. The only other representative data we could find was from BuddyBuild https://www.buddybuild.com/blog/source-code-hosting#selfhost... and has the same problem. You can see that it also isn't enterprise because the vast majority of their respondents is cloud hosted.

If there is a better data source we can use I would love to know. It seems hard to get data on self hosted organizations. Traditionally you looked at the number of paying customers, but that doesn't work with open source.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#72
post #67

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.

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.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#73

> 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.

I tend to believe claims of the form X is used by Y% of Z, but not give much weight to them because they are usually less impressive than they sound.

For example, I recall IBM marketing once claimed that OS/2 was used in some very high percentage (it was close to 100%, if I recall correctly) of Fortune 500 companies (or some similar group). Did that mean OS/2 was taking off in the enterprise, displacing Windows left and right?

Nope. It just meant that most Fortune 500 companies had at least one OS/2 system. Take advantage of its excellent DOS multitasking to migrate a few legacy DOS systems from dying old hardware to a single new machine under OS/2, and your Fortune 500 company counts as using OS/2 even if that is the only OS/2 system you have.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#74
post #71

Earlier quoted context omitted.

From bitrise link > We randomly selected 10,000 apps as a base "2/3 of all enterprises" can only be true if all enterprises are building apps on bitrise.

I do agree that the majority of Bitrise their population is not the enterprise at all. The only other representative data we could find was from BuddyBuild https://www.buddybuild.com/blog/source-code-hosting#selfhost... and has the same problem. You can see that it also isn't enterprise because the vast majority of their respondents is cloud hosted. If there is a better data source we can use I would love to know. It…

Inability to find the valid metrics you want is not justification to use invalid numbers.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#75
post #67

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.

I don't even know how to do that although I use git every day ^^

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.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#76
post #59

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-fe...

Fedora requires an FPCA. In the comments below 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 us…

Any major open source project which is accepting contributions with no agreement at all from contributors is asking for trouble.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#77
post #44

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?

Probably this link: 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 repo…

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...

This doc may also help: https://docs.gitlab.com/ee/workflow/repository_mirroring.htm...

Re: Debian and GNOME announce plans to migrate communities to GitLab

#78

Earlier quoted context omitted.

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".

> 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…

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.

Re: Debian and GNOME announce plans to migrate communities to GitLab

#79
post #71

Earlier quoted context omitted.

I do agree that the majority of Bitrise their population is not the enterprise at all. The only other representative data we could find was from BuddyBuild https://www.buddybuild.com/blog/source-code-hosting#selfhost... and has the same problem. You can see that it also isn't enterprise because the vast majority of their respondents is cloud hosted. If there is a better data source we can use I would love to know. It…

Inability to find the valid metrics you want is not justification to use invalid numbers.

These numbers are the most valid numbers we can find and match what we estimate based on other even less exact data (like the version check build into GitLab).

Re: Debian and GNOME announce plans to migrate communities to GitLab

#80
post #44

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?

Probably this link: 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 repo…

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/#me...), and hasn't been true for GitHub for a while (perhaps forever).
Post reply on HN