41–46 of 46 posts
Earlier quoted context omitted.
What server specs are working well for you?
Not OP but I have a number of gitlab instances: For 5 users we use 18G/4vCPU. For 20 users we use 32G/8vCPU I keep asking to lower the footprint but the gitlab is the very definition of feature creep. And that comes at the cost of optimisation.
Earlier quoted context omitted.
exactly my experience. Assuming that a powerful enough server is available to do that. Our first attempt to run gitlab on some small cheap VPS (2 cores, 4 gigs of ram) was a total disaster.
What server specs are working well for you?
I 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 feel like this is a non sequitur. There's no reason why breadth would increase outside contributions other than sheer surface area, but that relationship isn't very linear, especially if the surface area is being created by Gitlab rather than others.
Meanwhile, "polish" is often the unglamorous work which people typically don't want to do for free.
Try to imagine an exchange at Torvald's Bazaar and Emporium. Gitlabbers offer to work on the fun stuff and get paid for it. In exchange they ask everyone else to work on the boring stuff without being paid.
For some mysterious reason, this exchange fails to happen.
Earlier quoted context omitted.
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?
Ruby is like a back-of-the-napking sketch, almost: it takes nothing to get started, you can just jump in and start writing. Other languages are closer to gradations of a proper engineering diagram, the sort of thing you draw up once you've fleshed out your idea a little and want to scale.
As much as I hate bothering with a proper diagram, it's very hard to scale based on napkin sketches.
I 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…
Earlier quoted context omitted.
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.
Before doing that I had two situations where the major release broke something. Never looked back.