Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

221–230 of 325 posts

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

#221
Using gitlab for go development, "go get" doesn't work. Googled around, couldn't find a solution. With github, on the other hand, it just works.

I love gitlab (even made a git tool to easily create repositories from the commandline, gitgitlab) but these small things make a real difference. I'll end up paying for a github organization account just to get this annoyance out of the way.

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

#222
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 single project (for them to be able to read the code),  and we have also subcontractors, we would like to have a nice way to separate from the others
I think this things are most "day to day annoying", other than that gitlab is pretty good, the CI system, the hook system, it's pretty easy to put that links to issue section, ticket reference redirect to redmine , taiga , jira or whatever.

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

#223

Using gitlab for go development, "go get" doesn't work. Googled around, couldn't find a solution. With github, on the other hand, it just works. I love gitlab (even made a git tool to easily create repositories from the commandline, gitgitlab) but these small things make a real difference. I'll end up paying for a github organization account just to get this annoyance out of the way.

This should work, see https://github.com/gitlabhq/gitlabhq/pull/5958

Please open an issue with what you tried exactly.

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

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

Well, I can understand that having a business model which actually is stable and makes around FLOSS is hard, so I can tolerate a lot of wiggling around the edges of freedom. However, what I cannot tolerate is freedom of my data. Our IT guys are uneasy to installing supported version of GitLab internally (aside from the small question of money), because they are afraid that once we install EE version, we are locked into it. Is there a supported way how to get from EE to the true opensource version of GitLab and not to loose any data (aside from functionality not available in CE)?

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

#225
post #215
post #206

Earlier quoted context omitted.

1. For starters (besides other internal stuff), we were the guys who needed Shibboleth support. You might recall there were a few pull requests from a colleague of mine regarding that :) 2. No, we had to tweak the source, so I don't think the packages were useful. 3. Static pages, hooks and merge approvals would be right at the top of my list. Audits would be nice to have, but we figured out how to do that on our own…

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.

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

#226
post #224
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…

Well, I can understand that having a business model which actually is stable and makes around FLOSS is hard, so I can tolerate a lot of wiggling around the edges of freedom. However, what I cannot tolerate is freedom of my data. Our IT guys are uneasy to installing supported version of GitLab internally (aside from the small question of money), because they are afraid that once we install EE version, we are locked in…

Downgrading from EE to CE is officially supported. You can find the docs here: http://doc.gitlab.com/ee/downgrade_ee_to_ce/README.html

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

#227

I remember GitLab. They interviewed myself and a bunch of my colleagues to test the salary waters here in the Bay Area and hired nobody because we were all "overpriced", with several being underpaid for the area. If you want the talent you need, especially in the Bay Area, you have to pay more than what the average developer makes in Amsterdam. I want to like GitLab, but I just can't get that bad taste out of my mout…

We never interview people to test the salary waters, we know interviewing is serious for you and it is serious to us too. We're very aware of the salaries in SF (writing this from SOMA). But since we're a remote first company we can hire for anywhere in the world and because we're open source we get a lot of great applicants. So the bar is high and for the Bay Area it is even higher. Feel free to email me at sytse at company domain if you want to discuss your application.

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

#228
I'm one of the co-authors of the Dear GitHub letter. This is the type of response I want so badly from GitHub (but wasn't expecting).

GitLab still has a ways to go in terms of performance/reliability and polishing their product, but GitHub aught to be very nervous about them.

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

#229

I remember GitLab. They interviewed myself and a bunch of my colleagues to test the salary waters here in the Bay Area and hired nobody because we were all "overpriced", with several being underpaid for the area. If you want the talent you need, especially in the Bay Area, you have to pay more than what the average developer makes in Amsterdam. I want to like GitLab, but I just can't get that bad taste out of my mout…

Interesting. Yours is not the first account of a poor interview process with GitLab that I've heard. Even out of Texas, had a few colleagues that were very qualified and came out of it with a poor experience, to the point of changing their mind about wanting to work at GitLab.

I'm sorry to hear that, what was went wrong during our interview process?

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

#230

I'm one of the co-authors of the Dear GitHub letter. This is the type of response I want so badly from GitHub (but wasn't expecting). GitLab still has a ways to go in terms of performance/reliability and polishing their product, but GitHub aught to be very nervous about them.

Could you explain what still needs to be done? I use Gogs for personal use, but evaluated Gitlab briefly and it seemed about as polished, if not moreso, as Github to me.
Post reply on HN