Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

251–260 of 325 posts

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

#251

I've been using GitLab myself and suggesting it to any clients with the proper infrastructure. When I found GitLab I tried it out, and finally ended up moving my SVN to Git (private projects). It's a great piece of software and I love the web hooks.

That's great to hear. Any way we can improve web hooks for you?

Arguments from the project/push add to url would be great! A page outlining why you are better than gitblit would help with clients :-) (who are all possible future EE users)

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

#253
post #165

Earlier quoted context omitted.

Yes but Bitbucket has unlimited private repositories. So if your company has lots of projects compared to lots of people Bitbucket's pricing model is better.

GitLab.com is completely free, and has both unlimited private repositories and unlimited collaborators!

Except that it's unreliable, the website says so. Let me ask again, is there any plan without $390 onboarding provided by Gitlab that gives me following features:

1. Hosted Git. 2. Reliability.

There is none. I don't know why you seem to be trying to deny it. Your business obviously works with Enterprise. If I was a big corp, I'd be all over you. I'm not sure with Gitlab's compulsion with trying to make everyone happy. Even when they don't have a product that fit a nominal need in market (the 2 points above), they constantly try to insist that they do.

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

#254
post #61

Earlier quoted context omitted.

I said if I wanted hosted option, then their only reliable option is $390 onboarding. Which is true. If I must go on-prem, then I might just use git directly? Meanwhile at Github, $7 gives me hosted private repos. It's free on Bitbucket if I limit collaborators. The biggest selling point of these services is peace of mind and knowing someone is taking care of the code when I sleep. Otherwise, Git has always been a FO…

> If I must go on-prem, then I might just use git directly? Definitely. There's not much you can do with self-hosted GitLab that you can't do with pure git. GitLab just makes it easier, IMO. The main reason my company uses it is to restrict the master branch to certain people - doable with pure git, less effort with GitLab. There's no reason we couldn't use GitHub for this (wouldn't cost much for a team our size), bu…

True. There is no denying that on-prem Gitlab has its uses. Maybe not for me, but I can respect that.

The point I was making in the original comment was that Gitlab has absolutely no options without heavy onboarding that is hosted as well as reliable. I wasn't really undercutting their on-prem, just pointing out that comparisons with Github are heavily misplaced.

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

#255
post #225
post #215

Earlier quoted context omitted.

Thanks for your reply and for contributing code. 1. Shibboleth is now supported in the Omnibus packages https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inte... 2. Hopefully you can use the packages now that the Shibboleth code is merged. 3. GitLab Pages, git push hooks, merge request approvals and audit logs are available in EE.

Note that point 3 was an answer to the question > What features of EE belong in CE in your opinion? which means rcarmo knows they're in EE, but thinks they belong in CE.

OK, thanks.

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

#256

For me the big things missing (not only for big open source projects) 1. more than one level of subdivision for groups/projects (see below) 2. groups of users (call it department/team): because of 1 we have a lot of groups, (because all the small libs are in separate projects, so the project itself is a group, but of course we have several projects), so everytime somebody join the company, we have to add him in every…

Regarding:

1. Nested groups should solve that in the future https://gitlab.com/gitlab-org/gitlab-ce/issues/2772

2. We're thinking about that but for now the invite other group feature in EE will have to do.

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

#257

Earlier quoted context omitted.

> If I must go on-prem, then I might just use git directly? Definitely. There's not much you can do with self-hosted GitLab that you can't do with pure git. GitLab just makes it easier, IMO. The main reason my company uses it is to restrict the master branch to certain people - doable with pure git, less effort with GitLab. There's no reason we couldn't use GitHub for this (wouldn't cost much for a team our size), bu…

True. There is no denying that on-prem Gitlab has its uses. Maybe not for me, but I can respect that. The point I was making in the original comment was that Gitlab has absolutely no options without heavy onboarding that is hosted as well as reliable. I wasn't really undercutting their on-prem, just pointing out that comparisons with Github are heavily misplaced.

As said in other threads above, we are aware of the shortcomings of GitLab.com, but working very hard to resolve these [0].

Setting up your own instance is not hard [1], but we're also offering managed hosted instances on GitHost.io nowadays.

If you're still in the middle, you could use the one-click deploy options from providers such as Digital Ocean, Cloud 66 and AWS images [2].

[0]: https://gitlab.com/gitlab-com/operations/issues/42

[1]: https://about.gitlab.com/downloads/

[2]: https://about.gitlab.com/aws/#uw2

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

#258

Earlier quoted context omitted.

If you're looking for Mercurial try out RhodeCode, it support all the Mercurial specific workflows like phases etc. RhodeCode actually supports Git, Mercurial, and Subversion.

Is Rhodecode completely open source like Kallithea?

Consider reading http://ebb.org/bkuhn/blog/2014/07/15/why-kallithea.html for more background.

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

#260
post #248
post #132

Earlier quoted context omitted.

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

From first hand experience, Softlayer has been nothing but fantastic to us over the last few years, and cost effective.

Thanks, so far we're really happy about Softlayer.
Post reply on HN