Gitlab has provided the much needed competition with real impact (consider Github boards, for example) and you have a company that can pay many people a living. That is more than good enough.
The people that ask for fixes care about GitLab and are worth listening to. There is an almost infinite demand for new features and we can't make them all (even with more then 2000 open source contributors). But I've found that Hacker News readers have great insights and we'll keep listening and adjusting were we missed the mark.
GitLab as a company was born on Hacker News https://news.ycombinator.com/item?id=4428278 and although the tone these days feels like different I hope it is a bond for live.
One of the biggest problems I had was the speed of the web ui but since the great github migration the speed increased massively and has stayed snappy.
Contributing code to GitLab has also been my favorite experience with open source as not only were my changes looked at, Gitlab developers actually helped me get things working and write better code.
We made a lot of performance improvements, I'm glad you're benefitting from them. On https://about.gitlab.com/handbook/engineering/performance/#p... you can see what we're measuring. The monitoring of our biggest merge request https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-sum... shows of our fixes regressed and we're looking into what is going wrong. Screenshot for people reading this in the future: https://www.dropbox.com/s/nlriugkzknu2tl9/Screenshot%202018-...
There is a lot more work to do and we'll keep shipping performance improvements in code and to our infrastructure. The tentative date for our migration to GCP is next weekend.
I'm so glad to hear that contributing code to GitLab was a favorite experience! Kudos to our merge request coaches who try to get every merge request over the finish line with a high quality.
https://developers.google.com/web/fundamentals/performance/r...
They can also measure it live in the website, the median response time of API calls and so on.
Github has said this: "We’re quite obsessed with performance. We want to make sure the site is always performant and continually fast. For a Rails app, github.com is a really, really quick site and we have a motto that “It’s not shipped until it’s fast.”" https://medium.com/s-c-a-l-e/github-scaling-on-ruby-with-a-n...
They can create a performance measurement team, assign tickets based on what they find and prioritize them as part of ticket management. If something is too slow, then maybe it's time to refactor the underlying architecture or subsystem thats making things slow.
When glaring security issues sit open for a year, you need to understand GitLab is a problem for anyone who has regular security audits.
I am not asking for 100% redirection of resources to fix all the issues. I am suggesting they reprioritize resource allocation to lean more towards fixing issues that exist instead of new feature implementation.
I don't understand the attitude of people like you.
That said it is possible to improve the security of this kind of model, although there is a trade-off in availability. What can be done is that the decryption key (or a passphrase controlling access to it) is stored offline and manually input at application launch.
The downside is that if the application restarts it needs human intervention to be operational. the upside is that you reduce (but not eliminate) the risks of the credentials being compromised from that system.