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.
Dear open-source maintainers, a letter from GitLab
221–230 of 325 posts
Re: Dear open-source maintainers, a letter from GitLab
#222 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
#223Using 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.
Please open an issue with what you tried exactly.
Re: Dear open-source maintainers, a letter from GitLab
#224With 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…
Re: Dear open-source maintainers, a letter from GitLab
#225Earlier 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.
> 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
#226Earlier 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…
Re: Dear open-source maintainers, a letter from GitLab
#227I 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…
Re: Dear open-source maintainers, a letter from GitLab
#228GitLab 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
#229I 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.
Re: Dear open-source maintainers, a letter from GitLab
#230I'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.