If we would not have shipped new features and still did just just version control GitLab the company would not be viable. We're committed to shipping a single application for the whole DevOps lifecycle this year https://about.gitlab.com/2017/10/11/from-dev-to-devops/
But there are multiple performance tweaks en bugfixes going out every month, including this one.
Well, there's definitely a difference between periodically slowing down the new features for a month of additional focus on stability/performance improvements and 'just doing version control forever'.
Keep your fingers on the pulse of your customers. If the top comments in posts about your releases say "I wish they'd focus on quality more" even in a place where 'move fast and break things' is considered sage advice, then think of this as an indicator. If the performance improvements that have been going out every month are sufficient, the discussion would not focus on them as much.
I hope you see that I actively engage with our users and customers. We want to get the balance right. I think currently GitLab.com should be much more reliable and the RAM usage with should be lower. I'm happy with the improvements we are making in UX, polish, navigation, and loading times. They should all improve from today but we're making the right amount of progress.
Maybe a bit off-topic but some of our reliability improvements like Gitaly cause GitLab to use more memory. So improving non-functional requirements is not a single dimension.
Yes, do everything this anonymous person says, because their post has 3 upvotes.
Seriously though, listening to everything the community says is a certain recipe for failure. User feedback is an indicator, not more. Implementation details and the general direction of the software have to be based on sane decisions by the development team, not the community.
Please take my comment as playing devil's advocate, and not a negative "what do you think you're doing" question.
> If we would not have shipped new features and still did just just version control GitLab the company would not be viable.
Says who? I can name hundreds of enterprise software companies that don't ship new features on a regular basis and are still commercially very viable. In other words, what evidence do you have that if you spent 3 months just shipping performance improvements that it would slow your growth?
Thanks for asking. If you get back on the same pace after 3 months it would be acceptable. However I think this unlikely. From the linked page https://about.gitlab.com/handbook/ceo/#how-do-we-keep-shippi... "Don't ever slow down because it is very hard to recover from that. As soon as you stop shipping (for a big refactor, a security initiative, etc.) it is very hard to get back op to the old speed. The organization has accepted a slower rate and there are always enough reasons to go slower. You have to do the refactors and other things during the course of business, never slow down."
I think this is probably wrong. You need customers to love the product. Polish matters. Which is why github/slack is still used and loved more than bitbucket/hipchat.
Velocity for sake of velocity is not going to result in customer delight
I agree polish (user experience) is very important in winning people over. We think the worst user experience is between product categories in the DevOps lifecycle. Having to switch between JIRA, GitHub, circleCI, Artifactory, Ansible, and New Relic. We want to create a better flow. Therefore we have to balance polishing what we have with completing out vision of a single application for the DevOps lifecycle.
I'd love to use GitLab Issues over JIRA, but Issues is just so feature poor. I don't even need a complex bug tracker, but Issues doesn't solve any problem I can see, except very simple lists.
Just off the top of my head: How do you feel about CI/CD for gitlab? I mean in the sense of a publicly available unstable.gitlab.com where we warn users that everything will can get deleted at any time without notice? Maybe it is already possible?
> There is a cookie setting you can use to get some features early on GitLab.com but I can't find a link right now.
Andrew from the Infrastructure team at GitLab here: non-team members are welcome to use our canary service, provided they understand that service may at times we downgraded (they can always switch back to production when this happens).
We are not accruing technical debt to ship these features. Quite the opposite, because we ship the minimum viable change we keep things as simple as possible, preventing un-needed complexity that can slow us down later.
I like the perspective I recently read here that you should avoid the debt with a high interest rate. If you got a fundamental concept wrong and that mistake spreads throughout your codebase that is much worse than an isolated piece of code that could be better.
If we would not have shipped new features and still did just just version control GitLab the company would not be viable. We're committed to shipping a single application for the whole DevOps lifecycle this year https://about.gitlab.com/2017/10/11/from-dev-to-devops/
But there are multiple performance tweaks en bugfixes going out every month, including this one.
The big performance tweak in this release is the merge request view refactor https://about.gitlab.com/2018/07/22/gitlab-11-1-released/#me... which makes loading merge requests much faster but there are 35 other performance improvements https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=...
There were 141 bugs closed in this release https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...