A month of nothing but performance tweaks and bugfixes would be great though.
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...
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.
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.
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.
> 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?
Velocity for sake of velocity is not going to result in customer delight
Sometimes new features appear straightforward but the implementation details can be complicated. For example,
https://gitlab.com/gitlab-org/gitlab-ce/issues/18157
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.
We also test new features on dev.gitlab.org that runs a nightly build and is used by some of our team members.
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).
Details of how to toggle the canary environment can be found in our handbook: https://about.gitlab.com/handbook/engineering/#canary-testin...
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.
And it's a very good thing that their product allows you to self-host, because I have zero-confidence in their ability to properly operate infrastructure.
But the attention to detail/quality on the product itself is lacking too. Don't get me wrong, I love gitlab as a product, but they really don't seem to care about working on anything that doesn't let them check another box on a marketing feature sheet.
A selection of some issue I've filed...
Only took around a year to fix: https://gitlab.com/gitlab-org/gitlab-ce/issues/25388
Then this issue lingered for about a year before being closed because a customer filed a similar issue a couple months after I did... that other issue is still open though, so maybe they'll get around to it eventually: https://gitlab.com/gitlab-org/gitlab-ce/issues/25535
Here's one from two years ago that's still open: https://gitlab.com/gitlab-org/gitlab-ce/issues/19846
It's possible that issue is actually fixed now. I don't know and I don't care anymore.
Here another issue from 2 years ago: https://gitlab.com/gitlab-org/gitlab-ce/issues/19656
I filed that issue after a Gitlab person here on hacker news specifically invited feedback on UX/UI issues, and I had just spent a frustrating time trying to track down a runner.
At some point I just stopped filing issues & started ignoring the issues I'd already filed. The times they decided to close issues because they'd been open a long time certainly didn't inspire me to waste any more time trying to help them improve the product.
Closing & re-opening and re-tagging and doing everything but actually fixing the issue is not confidence inspiring.
Gitlab is still a great product, but now when I run into things that might warrant opening an issue, I just find ways of dealing with them on my own.
I cannot believe its not fixed it. They made the MR file view completely useless for us. It was a new "feature" that actually made things worse.
There have been a few different solutions proposed including adding a file tree to the merge request interface, so you can quickly see a full list of the files and how they relate to each other. There is a design discovery issue for adding a file tree to the merge request interface https://gitlab.com/gitlab-org/gitlab-ce/issues/49189 scheduled for the next release to work out the UX in more detail.
Would a file tree make reviewing a merge request easier for you? Thanks for the feedback, and would love to hear more here, or on the issue.
Normally new duplicate issues are consolidated into the oldest issue, but since both issues had been open a while ago I kept the issue that had the most participants and discussion open.
1. We consider stopping an environment https://gitlab.com/gitlab-org/gitlab-ce/issues/25388 a new feature, not a bug.
2. Relative submodule links are planned for 11.3 https://gitlab.com/gitlab-org/gitlab-ce/issues/37356
3. Not showing a retry option to logged out users https://gitlab.com/gitlab-org/gitlab-ce/issues/19846 is a good improvement but since very few logged out users will see this message we don't consider it a bug.
4. Showing the original project next to the runner IDs makes a lot of sense. As you can see in the issue we are no longer closing feature proposals due to inactivity.
If you find ways of dealing with above things on your own that involve modifying GitLab please consider contributing them back.
Adding new features is great, but making sure that the user experience around existing features is smooth/sensible/not frustrating is pretty important too.
The approach of shipping 80% solutions which take 20% of the effort probably got Gitlab to where it is today. But at some point the company is large enough and has enough resources that it's reasonable to expect that the difficult parts of the problem and the "polish" get addressed too.
We balance new major features, performance improvements and bug fixes https://news.ycombinator.com/item?id=17588352 and polish.
The vision of GitLab of a single application for the whole DevOps lifecycle is large and even though we have 160 engineers (including support) we can't do it all.
So if there are people who are proficient in Ruby we would love for them to submit improvements and join the 2000 people who already contributed code to GitLab.
Just to give an example of a recent redesign of an existing feature that I was involved in, it can be found here: https://gitlab.com/gitlab-org/gitlab-ee/issues/6089
Our application covers the whole DevOps lifecycle which means it takes a lot of effort to upkeep existing and constantly ship new features, but we always strive to do our best.
Thanks for the feedback, I think it will trigger internal discussions on how much time we should spend polishing existing features and experiences.
Thanks!
Edit: I wanted to clarify that if you’ve observed any undesirable behavior, we welcome you to log it and we will address it as soon as we can. I see how my original comment made it seem like we ship untested code. That’s not the case as Sid mentioned below. That being said, there might be specific edge cases or scenarios we have not captured in our tests. So problems do appear from time to time. So I wanted to invite anybody to log any problem so that we can reproduce it as soon as we can and get it fixed.
Also as Sid mentioned, this feature was recently brought to Core so that more users now have access to it.
I get Gitlab is going for "breadth over depth", but your company must ensure the features being promoted actually work.
Shipping untested code does not build confidence.
Changes can be minimal but they have to meet our definition of done https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU... that includes tests.
I assume the relevant product manager (Victor) hasn't heard this complain before but that doesn't show from his answer.
This feature was open sourced in 11.0 https://about.gitlab.com/2018/06/22/gitlab-11-0-released/#sq... after many people requested it https://gitlab.com/gitlab-org/gitlab-ce/issues/34591 but the code has been in use by users since GitLab 8.17 (Feb 22, 2017) https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1024 so I think that is why Victor assumed this was a user specific problem.