I chose Gitlab for my former company over GitHub Enterprise because we wanted an on-prem solution, and it worked well enough for ~200 folk. We did have to tweak (and occasionally break) a few things, since quite a few people suffered from NIH syndrome and wanted things done "the right way". In general, I liked it, but it always irked me that its Ruby underpinnings made it hard to upgrade/migrate stuff (we basically j…
Dear open-source maintainers, a letter from GitLab
121–130 of 325 posts
Re: Dear open-source maintainers, a letter from GitLab
#122My company with ~300 developers are moving to Gitlab in the next few months. Today our CTO/PM shared opinion about Gitlab and he was very happy we're doing it, even better I recommended it to him :) I'm a Gitlab users for a few years now, personally I like it much more than Github, one of the reason is that I fear that Github contains too many projects and gains too much control over OSS, I also dislike their CoS. Go…
Re: Dear open-source maintainers, a letter from GitLab
#123Earlier quoted context omitted.
> Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them. On a technical level that seems an impossible distinction to make. Someone want…
Yet, there is still differences. Allowing only "fork" is a good and easy thing. Having a fork that delete everything and start a new projet is easy to detect and label as spam. (there will always be abuses, but it's okay as long as you can mitigate/moderate)
Re: Dear open-source maintainers, a letter from GitLab
#124Just for this, I'm tempted: One issue that was raised several times was the ability to not create merge commits. In GitLab you can, as an alternative to the merge commits, use fast-forward merges or have merge requests be automatically rebased. The main thing keeping me from actually doing it is the network effect... and this: Disadvantages Right now GitLab.com is really slow and frequently down. This is because of f…
Very true, I think they are working very hard on improving the experience this quarter. Front page of HN probably does not help either. :)
Re: Dear open-source maintainers, a letter from GitLab
#125This 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…
Re: Dear open-source maintainers, a letter from GitLab
#126If GitLab plays their cards right, they can take the market from github. That, in my book, will be good because unlike github, we can all contribute to making GitLab better. The only question left is if your servers are powerful enough to run gitlab. Maybe I'll sacrifice a goat for some new server hardware and 256GB of ram.
Re: Dear open-source maintainers, a letter from GitLab
#127With 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…
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.
Re: Dear open-source maintainers, a letter from GitLab
#128It seems as the linked issue, for the "long list of suggestion", is being spammed or something? https://gitlab.com/gitlab-org/gitlab-ce/issues/8938 I have never used GitLab myself, but some of the features mentioned in the article (like a true voting system) is something I've really longed for. Might have to reconsider trying out GitLab more.
Re: Dear open-source maintainers, a letter from GitLab
#129Please improve your mobile UI - phones have lesser horizontal space than vertical. You have put a cool looking sidebar on the left side which takes up a lot of space causing text layout to be funny on my 5.2 inch LG G2. Github OTOH has an extremely usable mobile UI.
Re: Dear open-source maintainers, a letter from GitLab
#130Earlier quoted context omitted.
We are dealing with a lot of sensitive data and code which is legally not allowed to physically leave our group and GitLab is in my opinion the best open source choice for that. I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)
A good friend of mine likes to run https://gogs.io/ .. I havent used it heavily but Ive been impressed so far.