21–30 of 71 posts
> Realizing the future of DevOps is a single application
Google already realized the value of coupling their version control to CI years ago
Some will continue to prefer a self-hosted GitLab instance over GitHub, but requiring at least 4GB of RAM [1] for a low traffic instance sounds like an aberration. There should be better ways to manage memory consumption, and a lean GitLab instance that we have full control over could still be their selling point over GitHub. [1] https://docs.gitlab.com/ce/install/requirements.html#memory
Should GitHub dominate the market and gobble up competition, we all know how it goes for its parent company.
Someone send gitlab a box of tissues. And another box full of competent sysadmins.
Every time github releases a feature this is the response. These posts are so pathetic. I’m surprised that they continue to play this angle. It’s a very polarizing way to address the community that will definitely continue to stir up us vs them mentality between GitHub and Gitlab users.
Everything I hear about them screams immaturity, from deleting their prod db to smack talking competitors.
For all the bashing GitLab gets, personally, I want GitLab to survive and keep competing at some level with GitHub. Should GitHub dominate the market and gobble up competition, we all know how it goes for its parent company.
I'm happy with this competition.
I think what GitLab really needs is what a lot of open source projects are lacking: popular community forks. Their product development benefits from the community's QA feedback, but there are no community forks (that I am aware of) that are taking GitLab CE in directions that gitlab-org won't go. IO did this for Node and everyone has benefitted. I think GitHub's UX has caused new developers to lose true meaning of fo…
We had companies forking GitLab instead of contributing upstream, they all fell behind with upstream and couldn’t keep up to date anymore. Any examples of things you see that we at GitLab Inc. are not open to?
As more of the feature development goes into EE, there is less of a need to back port the latest changes. There are tons of workflow processes I would love to more tightly integrate with GitLab, but not all of them would make sense outside of my organization. Some of them can be hacked together with bots, but some of them require extending the core functionality and would probably require a fork.
> forking GitLab instead of contributing upstream
I think this is the problematic mindset. Meaningful contributions to upstream will follow useful forks.
> they all fell behind with upstream and couldn’t keep up to date anymore.
Code churn doesn't just slow down forks, it slows down core development.
Every time github releases a feature this is the response. These posts are so pathetic. I’m surprised that they continue to play this angle. It’s a very polarizing way to address the community that will definitely continue to stir up us vs them mentality between GitHub and Gitlab users.
What a strange post. GitLab is under siege from GitHub. The argument for GitLab has always been that they are more feature-rich, the argument for GitHub has been that their uptime is >80% and their UX is excellent. If GitHub achieves feature parity, GitLab is dead.
Maybe, assuming GH matches them at the same price points per feature and including self-hosting as a feature.
What a strange post. GitLab is under siege from GitHub. The argument for GitLab has always been that they are more feature-rich, the argument for GitHub has been that their uptime is >80% and their UX is excellent. If GitHub achieves feature parity, GitLab is dead.