Same issue, it seems to have become an "eierlegende Wollmilchsau" (German for Swiss Army knife, but with a negative conotation).
I recently move to gittea[1] for the very reason that I dont need 90%+ of Gitlabs features. Also Gitlab chews up RAM and IO, while gittea is barely noticeable even on a low end server.
[1] https://gitea.io/
I have to agree a bit on the "Eierlegende Wollmilchsau". Features are not everything, regressions and degraded core functionality impact current users, which will impact whether you are getting new users in the long run.
For example, recently the number of characters before line-wraps in the MR diff view changed. Not sure if this was intentional or accidental. I know two companies using Gitlab, both based the max-line length in their style-guide on what fit the diff-viewer. I guess Gitlab became a worse tool for code-reviews for them with that change.
"You need to optimize for the people not using your product yet because it is missing features." doesn't sound very fair to current users, and I don't think that will work long term.
Thanks for replying to this. The fluid settings will help, although it is not quite the same on small laptop screens as before the change.
At the same time I think the issue you link really highlights what some people have been saying: stable quality of the core product hasn't had the focus that customers would like it to have.
Apparently you changed the line-wrapping behaviour twice in a year, without even realising that 1) you changed it, and 2) that some of your customers rely on this being stable.
Of course you could argue that it was silly to rely on this behaviour, and that the new behaviour is in fact an improvement. But personally I think functional stability is
important to all customers, and the fact that this was not a deliberate change is odd.
Obviously such a small change will never drive away customers, but I do think quality is the difference between having users and having users that are also ambassadors that will recommend your product.
Thanks for that quote. I wrote that when we were much smaller. I now release it was worded to strong. I'll change it to something like: "You need to optimize for all people, both the current users and people not using GitLab yet because it is missing features" when I land.
I've asked Victor to look into the max line length change.
I agree that GitLab is using too much RAM. Stan Hu, all time MVP record holder, will start working to reduce this. Options are removing Ruby code in Gitaly 1.1 and using multi threading in the application server.
For every release GitLab gives an MVP award to the community member who contributes in an impactful way to that release. Stan has earned it the most times: https://about.gitlab.com/mvp/
Have you ever old software to an enterprise customer? Making your product look special by offering a bazillion features they will never use is surprisingly successful.
Only if you actually then invest some time in selling it. I've had radio silence from their sales team when requesting to purchase an self-hosted licence. The one thing I know about Microsoft (GitHub) - they _get_ enterprise sales.
Hi Simon, I work at GitLab. Sorry for the radio silence. I do know we prioritize follow up based on company size & order size. If a smaller company requests a few licenses it can slip through the cracks. I've tracked down your record in our CRM and am escalating to our sales team so that you get a response.
In our environment, a vendor would probably be better served to offer a no frills basics thing and then just sell customization support (or painless customization). You could probably check off every bulletpoint imaginable and then we would still have things that need customizing.
That sounds like Atlassian's products to me. That can backfire after a few years of use when every page is customized to hell and back and no one knows how it works.
No ones giving money for bugfixes, folks. People who pay money choose the product they are going to buy according to feature lists. Good enough quality is good enough.
It all depends on pro and cons. And if the gitlab people are doing this rather than fixing bug, is because they estimated that this is their best move right now.
In GitLab Starter, we have the export issues to CSV functionality, which includes two time tracking fields: time estimate and time spent. Is this the kind of reporting functionality you are looking for?
