> it just feels like Gitlab cannot compete

The GitLab hosted service is not really a competitor of GitHub at all; in fact, their (primary) marketing is based on self-hosted service.

In my opinion, this has connection to the corporate/engineering culture - GL relies on young and very sharp... but also underpaid minds, at least when compared to GH.

I speculate that in order to have a high performing and stable infrastructure, you need grey beards, who require salaries that GL doesn't offer. I highlight speculation - but I'm not surprised when the company losing 6 hours of data is one rather than the other.

If this is correct/realistic, it's not a negative judgment; it's just a different orientation.

Using gitlab.com with a group of ~20 devs - one of the main complains some of them had was 'It is slow'. From the last few months I hear more and more 'It is not so slow now, same as github'. So good job on all the performance improvements, users can feel them.

So it really depends how long in the past you are talking about :)

Thanks, glad you've noticed the improvements. We've still got more to do, but it's been an important part of every release for a while now.

seconded. I don't know whats been worked on in the past year, but its gotten a lot snappier overall.

What people don't understand about gitlab is that it's a absolutely monumental resource consumer.

I run one for a community of hobby developers and to keep my stuff out of github for ideological reasons, but it's running on what is, by _FAR_ the most beefy machine I run.

Normally I have machines that are a couple cores, couple gigs of ram, or single purpose machines with under 1G and a dedicated thread on the hypervisor.

Gitlab has a 32G DDR3/8 Physical core CPU machine to itself.

I consumes, at any given time, about 25% of that (before FS caches, which, you're going to want).

I had a friend running this before me on a VPS with 4G of memory and the thing was so annoyingly slow that we blamed the hoster and our users were turning back to bitbucket/github.

Since the upgrade, things are smooth as a babies butt.

Although it's hard to justify the SERIOUS expense of this server, it's certainly fast enough. I worry about larger deployments though.

Btw, you can get a taste for yourself if you like; https://git.drk.sc

Maybe it doesn't scale very well with many users/projects. We've only got a couple hundred projects and around 100 users. (and only a handful of CI runners)

Suggest gitbucket - https://gitbucket.github.io/

blazingly fast (a single war file - just run "java -jar gitbucket.war" to get started) and has a very nice UI. A plugin system enables you to extend the functionality (including CI) ... and a very active dev community.

https://gitbucket.github.io/

For anyone running this, can you comment? For example, one recurring criticism, before GitLab and the community managed to stamp out the expectation that it would be feasible, was that people were trying to self host a GitLab instance on a cheap SBC (e.g., a Raspberry Pi) or the smallest DigitalOcean plan and were surprised when this wasn't doable, while Gogs and Gitea handle this fine.

So to get a general idea of what sort of setup is expected in order to run a gitbucket instance, if you're running one, what are the relevant details?

Many thanks for the link, as Java/.NET dev it is surely a very good option to know about.

I love GitLab for the CI/CD which is absolutely second to none.

But I have to second the resource usage - GitLab runs on beefier machines than our production database cluster. We are throwing everything at it, and performance still sucks. Both in terms of UI responsiveness and CI builders which are around 2-3 as slow as a local docker build.

For example, we have not yet seen a good enough reason to migrate our production database to use NVMe disks. But for GitLab server and CI builders - very much so (for a modest boost in performance).

But then again, I still think I get my money's worth.

what I dont understand is that gitlab raised a very large amount of money - can it not pay a team in parallel to port it to golang or java ? Maybe the gitbucket or gitea teams are up for hire.

I tried gitea a while ago and it seemed very well featured while running much faster than gitlab. Single executable go app so it was also trivial to install.

I used both, and in my experience gitea/gogs starts out much faster than gitlab, but becomes slower and slower as repository sizes increase. At some point it became practically unusable, despite the repository not being particularly large.

On top of that we had constant issues with pull requests causing internal server errors, the merge check failing in mysterious ways, and so on. These issues may have been fixed now. We ended up switching to GitLab, and while it's quite resource intensive, performance seemed much more consistent.

Their docker image also goes up blazing fast compared to gitlab.

Also, they have repo mirroring which as I understand is not available on gitlabs CE edition.

Repository mirroring from several sources has been available in GitLab CE for several versions.

One-time, one-way mirroring has. Continuous push-for-push mirroring is still an EE feature.

> Btw, you can get a taste for yourself if you like; https://git.drk.sc

That's inaccessible over IPv6 along with what I presume to be the community's website (https://darkscience.net). As far as I can tell GitLab itself support IPv6 with ease, although gitlab.com doesn't (https://gitlab.com/gitlab-com/infrastructure/issues/645) due to limitations from Azure.

I believe this is a docker limitation (or, my version of docker limitation) I'll look into it.

Thanks for letting me know.

For lightweight use among friends, I found that gogs works much better for me. Has a tiny subset of features but reliably creates/manages repos.

https://gogs.io/

Sadly gogs for whatever reason doesn’t seem to actually use connection pooling or proper caching. It runs a new SQL query for every load of the "explore" site or a repo, which means I end up getting less requests/sec out of it than with gitlab.

Gogs is great. Gitea is a community fork of gogs if you're looking for more features as well.

Yes, the UI for issues and merge requests is atrocious with its light grey lines on a white background. I cannot skim a issue because I have to really concentrate on where a comment ends a new comment begins. Everything else also seems to float around in empty space, e.g. the emoji reactions.

Give me solid black lines for orientation, dammit.

Thanks for the feedback. I've created this issue for the UX team to discuss ways we can make this better. We agree, there are a lot of opportunities for improvement here.

https://gitlab.com/gitlab-org/gitlab-ce/issues/42331

I've been asking for this for well over a year. Nothing yet. I think they need a fairly fundamental shift in design thinking.

Hey Dan, Sarrah from the UX team here. I'd love to hear more about your thoughts here. Is there an issue you've created that you can point me to? If not, that's ok. Maybe you can tell me two or three UX changes we could make that you feel would have the most impact on MR and Issues.

Hi Sarrah, I raised it with the UX team in a feedback email a while ago.

It's not just an issue with merge requests or issues, it's more of a general thing – the colour palette and typography do not make GitLab easy to scan in the same way that GitHub is. I find it requires much more mental overhead to parse GitLab.

This, about the mental overhead. So much.

@Sarrah: I put some of my thoughts here: https://news.ycombinator.com/item?id=16214892

FWIW I agree with pretty much all of those points. Great to point out things like line length and container size.

Also possibly worth mentioning, I have the same problems with much of the marketing site and blog, not just the application.

I'll bite on the last part about the release candidates: Technically, in software, every stable release originally was the last release candidate in which no showstopper bugs were found.

Some decide to put in the extra work and rename that last working release candidate and remove the '-rcX' from the file names.

This may be, but Gitlab seem to push all of their RCs to prod.

I work for GitLab and I was responsible for introducing release changes for this cycle.

That is correct, we deploy our RCs to production. I consider RC as only a point in time snapshot of a release that will be sent to public.

One thing that is incorrect is that we push all our RCs to production. For example, this release RC1 did not get to GitLab.com because during deployment to our other environments we found an issue that could have caused a large problem at scale. However, we executed a lot of QA and FA tests against all our RCs. You can see this here https://gitlab.com/gitlab-org/release/tasks/issues?scope=all... .

If we only deployed a final release, we would most likely be overwhelmed with the amount of changes GitLab receives and it would be hard for us to monitor and limit the impact.

We are working on getting to continuous deployment to GitLab.com, and as part of this push we started right now with the tools we have at our disposal. One of the ideas to get to stable, non impactful deploys was to create many RCs. Thinking was that if we have a smaller delta between the RCs, we can more effectively check the changes and reduce the overall impact. We also wanted to make sure that we over-communicate our status updates so that we can get feedback in case we overlooked something.

Was it problem free? Nope. Did it limit the impact to users? I firmly believe so. We have a lot of work to do to get to blue-green deployments and continuous deployment on GitLab.com scale while we also continue to ship to on premise customers. I do believe that we will get there the best way we know how to, and that is iterating on changes.

> One thing that is incorrect is that we push all our RCs to production

I hadn't recorded them or looked it up, hence the use of the word "seem", but this is at least good to hear.

> Was it problem free? Nope. Did it limit the impact to users? I firmly believe so.

You may be right. It might have been worse, and perhaps releasing more frequent low-impact changes helped, but I'm somewhat unconvinced. Orchestration was known not to be stable; given that, I would typically try and minimise deployments until orchestration had been more comprehensively tested and/or staging/canary environments had better parity with prod.

Additionally, the deployments were done in the middle of work days (as has been mentioned elsewhere), at highly inconvenient times (just before Christmas!), with little to no warning to users, hinting that bad internal planning must have played some part. When queried, the reply was literally that there is no schedule[0] . This response does not instill confidence.

> I do believe that we will get there the best way we know how to, and that is iterating on changes.

I really hope this is true—I'm still using Gitlab myself—but while I was an advocate 6 months ago, I've very much put such advocacy on hold for the moment.

Also, just to mention, I really appreciate there are GL employees on HN commenting on these threads. I've received a reply before elsewhere (on perf. and Gitaly) and it's been enlightening and informative. I really do like the transparency in this organisation, and have done my best to be as patient as possible with the stability/perf. issues up until now. But it's really become a bit ridiculous at this stage.

[0] https://twitter.com/gitlabstatus/status/943574131425140736

> Additionally, the deployments were done in the middle of work days (as has been mentioned elsewhere), at highly inconvenient times (just before Christmas!)

It's always the middle of a work day in some part of the world. It's always going to be inconvenient for someone.

Do these updates really cause significant outages or just slower response times due to invalidated caches or whatever?

The dogfooding-preleases-on-Gitlab.com idea in general seems perfectly reasonable to me. They're the ones best equipped to deal with any resulting issues so catching them before the majority of on-premise users is going to hit them seems like a very good idea.

If they wouldn't do it, do you think the possible issues would magically disappear until GA? How?

The parent's point is that every production push everywhere was, at some point, a release candidate. Most people just rename that branch to remove the -rc suffix. Gitlab doesn't.

I get that, but I was just pointing out that while releasing a release candidate is fine, releasing multiple release candidates of the same version on production is slightly less fine.

Oh, I see what you mean now. Yes, I am inclined to agree there, although maybe their RCs are more akin to bugfix releases.

Jacob from GitLab here. Would love to help you out with your assignee dropdown taking 10 seconds. Currently on GL.com I see it takes 102ms. https://imgur.com/a/vSV21.

Also, I am wondering if you were looking at a much older version of GitLab with the discussion and the UI being unreadable. We've made a ton of improvements to our UI in the past year. If you are looking at a recent version, can you tell me what is unreadable about the discussions and the UI in general? That way we can fix it.

> the UI in general?

One thing I dislike very much about the UI in general is the fixed/sticky header, which wastes precious vertical space (especially with an Ultra Wide monitor since there's mostly nothing in it). Also due to its color I find it distracting when reading code, would love I could just scroll down to make it go away.

Most of the time I'm using the left sidebar, not the top one. For the few times I want to use the top bar, scrolling up really isn't an issue. Note that GitHub also doesn't have this.

Hello Jacob, glad to see Gitlab employees around!

For the assignee dropdowm, it was roughly 6-8 weeks ago. I just went back to an old project and things seem to be much faster now.

In the past 3 years, I had to work on Gitlab a few times (for a few months every time), and at the end of every project, I had this feeling of: it was slow (push speed at the time could take 5-10 seconds when it was almost instant on Github), and basically all request were slow (dynamic dropdowns, posting a comment...). It is good to see you are focused on fixing these problems though :)

For the UI thing, a few points:

- imho, there's just too much on screen. I would say Gitlab is to Github what IntelliJ is to Atom: too much features I don't want to use/see. They just distract me. - the container in the middle is too large, there too many word per line and things get hard to read - Even with the breadcrumb, it is really hard to see "where" I am in the app (which project) - In the issue details page, it is hard to see the continuity of the comments, what is a comment and what is an action ("assignee changed from to..."). I cannot quickly go through an issue an getting on overview of the discussion easily.

I think these are mostly tiny UI things to change, and only with some typeography improvements, some borders and better contrasts, things will be a lot more clear.

Of course, all of this is highly subjective.

5mn of CSS tweaks: https://imgur.com/a/FLTJT (ofc it adds other issues/concerns, but you get the idea, I am no designer, but sensible to nice UIs)

"I think these are mostly tiny UI things to change, and only with some typeography improvements, some borders and better contrasts, things will be a lot more clear." YES! Couldn't agree more. We (the UX Team) are pushing hard to get changes like this in. I opened up a new issue to capture the comments here https://gitlab.com/gitlab-org/gitlab-ce/issues/42331. I will add your insights to the issue, much appreciated! And...LOVE that you used that example in your 5min tweak <3

I use it at work and haven't had anything to complain about, but we are using the self-hosted version.