[ploggingdev]

I get the impression that Gitlab focuses a little too much on releasing new features at a rapid pace with every release. Maybe they should spend more time on running their infrastructure reliably and getting their engineering practices up to speed. The recent events will raise a red flag with enterprises who might be potential Gitlab customers and that directly affects their bottomline.

[shakna]

Gitlab.com is for testing new features. It's a testing environment.

If anything, enterprises can rest easy, because the next version has already been running in the wild, with a real world group of users running on it.

This was a first RC. It's fairly normal that infrastructure problems can arise here.

[swozey]

Yeah, I run Gitlab-EE internally and am aware of gitlab.com being a test bed but I can definitely see how others less familiar with Gitlab aren't aware of that.

Taking a quick glance at their site I can't even find anything about it basically being the test bed. There used to be some lines last year that said something along the lines that gitlab.com was known to be unstable and they recommended important projects to be self hosted. Maybe it was in the docs, I forget.

They should probably emphasize that somewhere if that's still the route they're going, although I feel like I did read they're working on major stability/infrastructure upgrades to solve those issues.

I don't pay much attention to gitlab.com since I use my own ee.

[sytse]

We're working to make GitLab.com faster in https://gitlab.com/gitlab-com/infrastructure/issues/947

[revelation]

The real gem (pun intended) of Gitlab is not Gitlab.com, but the open source self-hosted version.

Chances are I don't want them to improve their infrastructure to the point where it can be a Github 2.0, because that probably means the setup and ongoing maintenance requirements of the self-hosted version will become excessive to support a scale that nobody using it has.

[cptskippy]

I questioned their engineering competence during their last outage and the general responses I got were very dismissive. Gitlabs were able to spin the last disaster into a publicity stun with the live streaming but I feel like that was a fluke. Bro coding and "openness" will only garner you so much good will with paying customers who are more concerned with availability.

The unavailability of a code repository might be more of an inconvenience for a single developer but in an enterprise environment with teams of coders being able to quickly disseminate code changes can be critical. The unavailability of a source repository becomes a huge liability and a waste of man hours.

[xena]

If you are relying on something for your business that you paid nothing for, you get your money's worth.

[cptskippy]

That excuse doesn't really work because Gitlab offers a premium paid option for repositories hosted on Gitlab.com.

[Perihelion]

.com is free -- paying customers/CE users weren't affected by the outage.

[cptskippy]

> .com is free

Yes, and Gitlab.com Bronze Support is a premium service offered on the Gitlab.com platform. It is not the hosted or self hosted premium offerings.

> paying customers/CE users weren't affected by the outage.

That is incorrect. If you pay for Bronze Support you are definitely affected by this outage. Hosted and Self-hosted customers are unaffected.

[Piskvorrr]

Which is why I have yet to see a company with a gitlab.com important repo - but Gitlab local installs? Aw yeah! (Gitlab EE is their main focus, IMHO - providing a public Github alternative seems to be an afterthought.)