Re:What’s Next for Gitlab CI: Auto DevOps
by cyphar on Friday July 07, 2017 @07:24AM
(#14717576)
> Gitlab's UI is bad-ish (this is what made me consider going to work there/contributing and helping fix that)
If you'd asked me a year ago, I would've said some very harsh things at this point. But I just went to find examples of the issues I had a year ago (and we still have on our own internal GitLab instances), and it looks like most of them have been resolved. There's still weird duplication (why is there still a "Repository" tab when you can see the repo on the front page) but that's all just small warts that don't matter as much.
I think GitLab still suffers from a weird workflow, but it's much better now than it was in the past.
> Gitlab is slow.
The reason why this is an issue is not the fault of the technology imo, but rather a fault of the marketing and community. GitLab is not meant to usurp https://github.com. It's meant to be a viable alternative to GitHub EE.
Unfortunately, there appears to be a split-brain in the community. GitLab themselves are saying that https://gitlab.com has scaling issues that they are working on resolving, but that self-hosting will not have these issues unless you're planning on running at the same scale as them. But the community appears to want more people to swap away from https://github.com to https://gitlab.com (that's the impression I get).
By doing that, you've now said "any comparisons between https://github.com and https://gitlab.com are entirely valid because we're advertising them in the same capacity". That's selling yourselves short.
If GitLab had decided to go for a federated model, then this sort of marketing problem wouldn't be nearly as much of an issue (you would run into the Mastodon effect, where everyone joins the "official server" -- but if you made it possible to migrate the users, permissions, issues and state of the repo then it wouldn't be a long-term concern). They didn't, and that's fine, but that means that marketing https://gitlab.com as a replacement for https://github.com is going to just cause problems.
If you'd asked me a year ago, I would've said some very harsh things at this point. But I just went to find examples of the issues I had a year ago (and we still have on our own internal GitLab instances), and it looks like most of them have been resolved. There's still weird duplication (why is there still a "Repository" tab when you can see the repo on the front page) but that's all just small warts that don't matter as much.
I think GitLab still suffers from a weird workflow, but it's much better now than it was in the past.
> Gitlab is slow.
The reason why this is an issue is not the fault of the technology imo, but rather a fault of the marketing and community. GitLab is not meant to usurp https://github.com. It's meant to be a viable alternative to GitHub EE.
Unfortunately, there appears to be a split-brain in the community. GitLab themselves are saying that https://gitlab.com has scaling issues that they are working on resolving, but that self-hosting will not have these issues unless you're planning on running at the same scale as them. But the community appears to want more people to swap away from https://github.com to https://gitlab.com (that's the impression I get).
By doing that, you've now said "any comparisons between https://github.com and https://gitlab.com are entirely valid because we're advertising them in the same capacity". That's selling yourselves short.
If GitLab had decided to go for a federated model, then this sort of marketing problem wouldn't be nearly as much of an issue (you would run into the Mastodon effect, where everyone joins the "official server" -- but if you made it possible to migrate the users, permissions, issues and state of the repo then it wouldn't be a long-term concern). They didn't, and that's fine, but that means that marketing https://gitlab.com as a replacement for https://github.com is going to just cause problems.