dblessing

Please see Sid's comment at https://news.ycombinator.com/item?id=18443014. The numbers are from two separate points in time.

Sorry for the delay. Due to the spike in imports things are a bit backed up. Your import should be in the queue and will run eventually. As someone else mentioned it can take a lot of time to import, in general, depending on the number of issues, PRs, etc. Contact @movingtogitlab if you continue to have trouble.

GitLab.com offers private repos with unlimited users/collaborators for free. You even get 2,000 free CI minutes per month per group.

Thanks for your concern. Everything on https://monitor.gitlab.net is for public consumption. We're very transparent :)

Sorry about that. Was the 503 on GitLab.com (main application) or on the link in this discussion (monitor.gitlab.net)? The latter is to a public monitoring dashboard. It has been offline a couple of times today due to influx of traffic. We're closely monitoring it and attempting to keep it online. At the moment, GitLab.com itself has been absorbing the additional load, though. Let us know if you're seeing other issues.

Sorry about that. We had to scale our monitoring dashboard due to increase in traffic.

It went down again for a short time. We're continuing to monitor and adjust resources as needed. We weren't expecting this traffic to our monitoring dashboard, but it's great that so many people are interested in taking a look.

I like your idea. However, few performance problems are global. We have a public monitoring dashboard at https://monitor.gitlab.net/. Embedded in this dashboard are various metrics which will often show a drop in response time if we improve performance on a particular item. We usually find a page or set of pages that hit a particular bottleneck and improve that one point. Also, you will usually see mention of specific performance improvements in the changelog (https://gitlab.com/gitlab-org/gitlab-ce/raw/master/CHANGELOG...) and in our release blog posts.

Thanks for the kind words. I'm glad you like the swag and enjoy using GitLab.

Thanks for your concern :) Many from our team are indeed on high alert.

Sorry about that. We had to scale our monitoring dashboard a bit. It's back up at the moment. GitLab.com is separate infrastructure, though, and we hope it remains online despite the added traffic :)

Sorry about that. We had to scale our monitoring dashboard a bit. It's back up at the moment.

Turnkey is a great way to get GitLab up and running. However, please note that the latest version of Turnkey is based on GitLab version 8.3 (https://www.turnkeylinux.org/updates/gitlab) which is nearly 2.5 years old. Check out http://about.gitlab.com/downloads for information on various installation methods which make it easy to install and keep GitLab updated.

Sorry about that. The link from this discussion is to our public monitoring site (separate from GitLab.com). GitLab.com itself it online and the monitoring dashboard is working again, too.

Sorry about that. The 502 was only on our public monitoring dashboard for a short time. GitLab.com itself is up and running and the monitoring dashboard is back online now.

The Sidekiq memory killer is enabled for both CE and EE by default with the Omnibus package. If you're seeing something different please let us know and we'll see what's going on.

Thanks for sharing your experience with GitLab support. I'm happy to follow up on your issue if you reference your ticket number.

We absolutely want to help every customer have a good experience. When we fail at that we want to do everything possible to turn it around. I look forward to helping you.

Sorry to hear you're having trouble scaling GitLab. We have many organizations running GitLab and successfully scaling to 10's of thousands of users, and GitLab.com which is the largest GitLab installation. As a GitLab Enterprise customer our support team is happy to help you review your scaling problems and resolve them. Please submit a support request at https://support.gitlab.com.

> Does this mean if the account has private repositories, even if unused / dormant, that a username cannot be freed?

Correct. We understand that sometimes users will be dormant for a while and when they have data of any kind, we have to give them the benefit of the doubt.

Please send us an email at support at gitlab to start the process.

I'm glad you love using GitLab to manage your automation projects. Luckily, you can still use the Omnibus install but change the default usernames :) In `/etc/gitlab/gitlab.rb` we have the following configuration options:

registry['username'] = "registry" registry['group'] = "registry" user['username'] = "git" user['group'] = "git" postgresql['username'] = "gitlab-psql" redis['username'] = "gitlab-redis" web_server['username'] = 'gitlab-www' web_server['group'] = 'gitlab-www' mattermost['username'] = 'mattermost' mattermost['group'] = 'mattermost'

Change these to acceptable values and it should work well for you. If there are any other blockers in the Omnibus package, please create an issue at https://gitlab.com/gitlab-org/omnibus-gitlab/issues and we'll do our best to accommodate them.

Thanks for recognizing our Core Team, too. They're an integral part of our community. :)

We are investigating what it will take to enable this on GitHost.io. At first glance, it doesn't seem to be too difficult. I created https://gitlab.com/gitlab-com/githost/issues/12 to track this feature request.

In EE there is a nightly LDAP sync worker that will auto-block any LDAP users that are no longer in the directory. This should address the active user count issue for licensing.

This is definitely not normal. For 20 users, 8GB is more than enough and it should not require constant restarts. Please check out https://about.gitlab.com/getting-help. Message me on Freenode #GitLab @ dblessing or Twitter @drewblessing or @GitLabSupport. I'm happy to help.