Thank you Gitlab for the amazing product and transparency. Just watching the conversation as everyone over there is trying to get to the root of the problem is inspiring. What a strategy.
Degraded performance on GitLab.com
31–40 of 46 posts
Re: Degraded performance on GitLab.com
#32I recently started a new position at a company that is using Gitlab. In the last month I've seen a lot of degraded performance and service outages (especially in Gitlab CI). And then I see stuff like this that makes me scratch my head: https://about.gitlab.com/product/service-desk/ If anyone at Gitlab is reading this ... please, please slow down on chasing new markets + features and just make the stuff you already ha…
For a bit more about WHY we choose breadth over depth - We believe that the company plowing ahead of other contributors is more valuable in the long run. It encourages others to contribute to the polish while we validate a future direction. You can read more on our company strategy page - https://about.gitlab.com/company/strategy/#breadth-over-dept... As open-source software we want everyone to contribute to the ongo…
"We're Open Source!" isn't a valid defense when you have paying customers. That pitch sounds great for your VCs, but for someone who spends a portion of their budget on your cloud services - i'm appalled.
Gitlab is a SaaS company who also provides an open source set of software. If you don't want to invest in supporting up time - then don't sell paid SaaS services.
Re: Degraded performance on GitLab.com
#33GitLab is best (imo) as a private instance; we haven't had any issues with it after using it for 3 years now
Gitlab has lots of problems. It runs slowly unless you throw tons of hardware at it, and has lots of bugs. Our devops guy burns tons of time keeping it running. There are too many parts to it; too many services. And ruby is just not meant to be used in production stuff, particularly not of that scale.
Re: Degraded performance on GitLab.com
#34Earlier quoted context omitted.
Right? This is EXACTLY what I want to see when there's a service disruption. A live, in-depth view of who is doing what, any new leads on the issue, multiple teams chiming in with various diagnostic stats, honestly it's really awesome. I know this can't be expected from most businesses, especially non-open sourced ones, but it's so refreshing to see this instead of the typical "We're working on a potential service di…
I think it's cool but I'd be totally self-aware and fearful or making the idiot post in the thread for HN to judge :p
It's certainly something I'd be scared of too. It's honestly really brave of them to approach it this way, but I do enjoy watching them work :D
Re: Degraded performance on GitLab.com
#35Earlier quoted context omitted.
For a bit more about WHY we choose breadth over depth - We believe that the company plowing ahead of other contributors is more valuable in the long run. It encourages others to contribute to the polish while we validate a future direction. You can read more on our company strategy page - https://about.gitlab.com/company/strategy/#breadth-over-dept... As open-source software we want everyone to contribute to the ongo…
"We're Open Source!" isn't a valid defense when you have paying customers. That pitch sounds great for your VCs, but for someone who spends a portion of their budget on your cloud services - i'm appalled. Gitlab is a SaaS company who also provides an open source set of software. If you don't want to invest in supporting up time - then don't sell paid SaaS services.
Your logic and reason have no place in VC land.
They need more users!
Re: Degraded performance on GitLab.com
#36GitLab is best (imo) as a private instance; we haven't had any issues with it after using it for 3 years now
Gitlab has lots of problems. It runs slowly unless you throw tons of hardware at it, and has lots of bugs. Our devops guy burns tons of time keeping it running. There are too many parts to it; too many services. And ruby is just not meant to be used in production stuff, particularly not of that scale.
What is Ruby meant to be used for, if not production software?
Re: Degraded performance on GitLab.com
#37I recently started a new position at a company that is using Gitlab. In the last month I've seen a lot of degraded performance and service outages (especially in Gitlab CI). And then I see stuff like this that makes me scratch my head: https://about.gitlab.com/product/service-desk/ If anyone at Gitlab is reading this ... please, please slow down on chasing new markets + features and just make the stuff you already ha…
For a bit more about WHY we choose breadth over depth - We believe that the company plowing ahead of other contributors is more valuable in the long run. It encourages others to contribute to the polish while we validate a future direction. You can read more on our company strategy page - https://about.gitlab.com/company/strategy/#breadth-over-dept... As open-source software we want everyone to contribute to the ongo…
Wait, you are saying that your current customers aren't valuable?
Thanks, I am now convinced that I'll never do business with GitLab.
Re: Degraded performance on GitLab.com
#38Earlier quoted context omitted.
> please, please slow down on chasing new markets + features and just make the stuff you already have work properly I really agree with this. I was working at a company where we were exploring switching from Github enterprise to Gitlab for the K8s integrations, the docker registry, and the CI features. Following the helm chart installation instructions was a nightmare because we were on-prem w/ a custom cluster. Ther…
> When it comes to on-prem or self-hosted software I actually prefer running a monolithic application that worst-case I can just bounce or reboot the server. So why not just skip the helm chart and install the omnibus package on a dedicated server? If you want you can even disable stuff like the omnibus Postgres/Redis/etc and manage those yourself elsewhere. That's what I do - run the omnibus package sans fancy helm…
> That's what I do - run the omnibus package sans fancy helm chart - and it works out pretty well.
Can second that. Hosting a instance for our (quite small) dev team on a kinda-small VM and the GitLab Omnibus Package has been one of the nicest (while biggest) piece of software to administrate. Updates are super smooth, the things we use seem to be stable over the last two years. Only three unplanned downtime’s in that time and all because our hoster is plain terrible (hi Telekom!).
Re: Degraded performance on GitLab.com
#39GitLab is best (imo) as a private instance; we haven't had any issues with it after using it for 3 years now
There have been a number of updates in the last 3 years that would have completely broken or caused 500 errors on your Gitlab instance if you immediately updated it prior to a hotfix being released. If you didn't encounter these I would be shocked or you're keeping off bleeding edge releases (smart). I've managed private gitlabs for 4-5 years. I've submitted ~5-10 tickets regarding various things breaking (gitlab-run…
I found that the good old “skip the .0 release” goes a long way.
Re: Degraded performance on GitLab.com
#40I recently started a new position at a company that is using Gitlab. In the last month I've seen a lot of degraded performance and service outages (especially in Gitlab CI). And then I see stuff like this that makes me scratch my head: https://about.gitlab.com/product/service-desk/ If anyone at Gitlab is reading this ... please, please slow down on chasing new markets + features and just make the stuff you already ha…
For a bit more about WHY we choose breadth over depth - We believe that the company plowing ahead of other contributors is more valuable in the long run. It encourages others to contribute to the polish while we validate a future direction. You can read more on our company strategy page - https://about.gitlab.com/company/strategy/#breadth-over-dept... As open-source software we want everyone to contribute to the ongo…
I think I understand the perspective, but the messaging sounds a bit like, "Pay us full price while serving as our beta tester; sacrifice the needs of your company so you can fulfill the needs of ours"