Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

131–140 of 325 posts

Re: Dear open-source maintainers, a letter from GitLab

#131

Earlier quoted context omitted.

Most people associate a lack of reliability with anything Microsoft-related. Although I do not think that is the cause of Gitlab's problems.

Reading their Twitter status messages. Microsoft sponsored Azure for Gitlab. Between Oct and Dec they were on Azure, and they had major issues with the Azure platform, pretty unreliable for their use case. Gitlab switched to IBM Softlayer because of that experience. Read yourself: https://twitter.com/gitlabstatus and https://gitlab.com/gitlab-com/operations/issues/17

It seems they have switched back to Azure now. In my own (very limited and small-scale) experience, Azure is pretty solid. Although some of the APIs seemed a bit unnecessarily convoluted compared to AWS (can't recall any specific instance).

Re: Dear open-source maintainers, a letter from GitLab

#132

Earlier quoted context omitted.

Most people associate a lack of reliability with anything Microsoft-related. Although I do not think that is the cause of Gitlab's problems.

Reading their Twitter status messages. Microsoft sponsored Azure for Gitlab. Between Oct and Dec they were on Azure, and they had major issues with the Azure platform, pretty unreliable for their use case. Gitlab switched to IBM Softlayer because of that experience. Read yourself: https://twitter.com/gitlabstatus and https://gitlab.com/gitlab-com/operations/issues/17

Although we planned to switch to Softlayer we're still on Azure. It has given us a hard time, but in the last few weeks things have gotten more stable. Our availability is better (fingers crossed) but our speed is still unacceptably slow https://gitlab.com/gitlab-com/operations/issues/42

Re: Dear open-source maintainers, a letter from GitLab

#133
post #127
post #111

Earlier quoted context omitted.

We would love to help you to host VideoLAN on a on-premises GitLab instance. Thanks for raising the issues you did. 1. Our EE version has the function share project with other groups http://doc.gitlab.com/ee/workflow/share_projects_with_other_... If this is essential for you we'll give you a free lifetime license for GitLab EE. 2. You can add custom labels on issues and the searches can be stored in urls that you can…

[videolan infra guy here] The whole idea of VideoLAN infrastructure migration from gitweb/trac/etc to gitlab and not to github was to use and promote free and open-source software. Using closed-source software there is out of question, really.

Gitlab EE is actually open source. https://gitlab.com/gitlab-org/gitlab-ee

Re: Dear open-source maintainers, a letter from GitLab

#134

Any chance you can support Mercurial? There was a highly voted issue that I saw sometime back.

We'll not support Mercurial, this would be an additional layer of indirection and limit us to features that are supported in both Git and Mercurial.

Re: Dear open-source maintainers, a letter from GitLab

#135

Both products are really good, but Github needs to realise that they have to be more open and listen more to their users. There is an opportunity for Gitlab here and I'm happy that they decided to make this announcement. The community is the actual winner of this healthy competition.

Thanks alexbardas!

Re: Dear open-source maintainers, a letter from GitLab

#136
post #111
post #9

With VideoLAN, we're not on github, but I believe we fit the 'large open source project' description. We host VLC, FFmpeg, x264 and quite a few related libraries. For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure. And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting th…

We would love to help you to host VideoLAN on a on-premises GitLab instance. Thanks for raising the issues you did. 1. Our EE version has the function share project with other groups http://doc.gitlab.com/ee/workflow/share_projects_with_other_... If this is essential for you we'll give you a free lifetime license for GitLab EE. 2. You can add custom labels on issues and the searches can be stored in urls that you can…

Thanks a lot for the answer and the proposal. But we do not want to have anything critical that is not open source. We try to promote OpenSource, so using non-open-source software is hard to do.

1. Thanks, but see above :)

2. As I said, custom labels are way too limited, as people on the open-letter-to-github said, so I will comment on the issue.

3. Will do.

4. same as 1 :) But thanks a lot.

I will contact you :)

Re: Dear open-source maintainers, a letter from GitLab

#137

Perhaps if they had the same uptime, page load speed and UX as Github, I would consider it. Unfortunately we tried it for a week at work and none of us could figure out our way around it (when it was working).

I'm sorry that GitLab.com was unavailable an slow. As mentioned on https://about.gitlab.com/gitlab-com/ we're working on that. Have you considered self-hosting it?

Re: Dear open-source maintainers, a letter from GitLab

#138
post #127

Earlier quoted context omitted.

[videolan infra guy here] The whole idea of VideoLAN infrastructure migration from gitweb/trac/etc to gitlab and not to github was to use and promote free and open-source software. Using closed-source software there is out of question, really.

Gitlab EE is actually open source. https://gitlab.com/gitlab-org/gitlab-ee

The GitLab EE source is publicly viewable, but its license is not open source. See https://about.gitlab.com/2015/05/22/gitlab-7-11-released/.

Re: Dear open-source maintainers, a letter from GitLab

#139
post #65

Somebody just spammed their Issues page[1]. The one they link to in the letter. I think the spammer is trying to make a point! For starters, there seems to be no rate limit applied. [1] https://gitlab.com/gitlab-org/gitlab-ce/issues

GitLab has rate limiting on the API http://doc.gitlab.com/ce/security/rack_attack.html but by default we set it pretty high.

Re: Dear open-source maintainers, a letter from GitLab

#140
post #70

This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems a little low-brow. Why respond to a letter that's not addressed to you? I would have preferred them to simply post an honest "Why you should migrate from Github to Gitlab" article. The tone just seems a little devious to me. By the way, we're using self-hosted Gitlab at work and we love it. This isn't a knock against the actual product. In…

> This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems a little low-brow.

I can hardly imagine a better outcome. Now both GitHub and the developers have a choice to make; GitHub can either ignore the complaints or take them into account, and people can either continue using GitHub or start using GitLab (or something else). Nothing better than informing people in a kind, respectful manner.

Post reply on HN