Live data from Hacker News

Maturity

about.gitlab.com

81–90 of 127 posts

Re: Maturity

#81

Gitlab is slow. It’s so unbearably slow, even their official server. Guys, why should a static content load after page loading is done? Page loading done, and the code still loads with a loading circle. Why? Just compare it with github. Average 500ms makes a huge difference. Also gitlab UI is a huge mess. It got all the features, sure. But the UI is not that user friendly. Don’t use flat the wrong way. Use contrasts…

Yeah speed is the only reason why i won't give Gitlab another try. All these features are great. But i don't believe they will help them with market share until they have addressed the speed issue.

After August was filled with performance related problems on gitlab.com, they actually managed to fix a quite a lot of inefficiencies and more to come.

Plus you can make it as fast as you want if self-hosing is an option by throwing more hardware at it.

Re: Maturity

#82

Gitlab is slow. It’s so unbearably slow, even their official server. Guys, why should a static content load after page loading is done? Page loading done, and the code still loads with a loading circle. Why? Just compare it with github. Average 500ms makes a huge difference. Also gitlab UI is a huge mess. It got all the features, sure. But the UI is not that user friendly. Don’t use flat the wrong way. Use contrasts…

Tbf, GitHub is (at least in my opinion) also slowly overcomplicating its UI with all the new features they add

True, but gitlab already did that :(

Re: Maturity

#83

Gitlab isn't big company, 100 devs or so, they try to target much bigger fish (>2000 devs) with their product, yet they can't make it work even for their scale: Kubernetes , monitoring, CI workflows like merge trains and others. So when it comes to putting you money (gitlab.com subscribers) where you mouth is (gitlab.com/features page) they are not there yet. Kubernetes story is quite telling. They released "cloud na…

Their product marketing pages always remind me of those "kitchen nightmares" shows.

On this episode, an over-ambitious family restaurant decides to expand like crazy and ends up with a huge menu of stuff that the overworked chefs can't cook properly.

Some TV chef should be yelling at them for wasting the opportunity of a lifetime by ignoring good business sense, or something like that.

Re: Maturity

#84

Earlier quoted context omitted.

It's not that the DAG feature isn't useful to me, the problem is that it has to coexist with a badly engineered version (the stage based model) which should never have been released in the first place. It is better to have GitLab not support CI runners than it is to push something that is so badly engineered. Better to delay that feature for 6 months than to increase the amount of legacy you push downstream to your u…

Ah, I understand. We do have users who prefer the stage model or hybrid DAG mixed with stages, but I get that that isn't your point of view. I do hope that after the next couple releases it becomes something more useful for you - your use case is important too. Releasing early to get feedback on issues is important to us but we can do better communicating around what's an early preview vs. a mature feature. The matur…

Sorry if I am a bit frank, but I simply do not believe you when you say you have users who prefer the "hybrid DAG mixed with stages". That's a bit like Microsoft saying that there are users who enjoy the 255 character path limit. My use case isn't an "improved DAG model", it is a DAG model without the pointless restrictions introduced by broken legacy.

In the DAG model (which really is just the model implemented by every sane build tool ever made), stages give you no extra expressive power, they only add arbitrary restrictions to that model and aren't useful at all.

Re: Maturity

#85
Very pretty graphics and a good way to see a complete listing of products they offer.

I fear that GitLab has simply bitten off more than they can chew. They try to implement so many features that many things feel half-baked. Ultimately - those features that aren't finished are useless to paid or enterprise subscribers.

GitHub has been successful because they focused on doing one thing very well. Now that they have established market dominance, they are slowly introducing new features - but in a way that makes them feel like useful pro-level products right away.

I don't know how GitLab recovers from that other than continuing to march forward. If I were them, I would stem the tide of new product introduction and focus on building out what is already there. It's a very ambitious roadmap they have given the number of features they want to implement.

Re: Maturity

#87
post #19

Earlier quoted context omitted.

The Product Manager (in the case Jason Lenny who is out of office today) prioritizes between bugs, vulnerabilities, new features, and tech debt. He or she uses customer input, user input, and company input. Read more on https://about.gitlab.com/handbook/product/#prioritization To find the relevant Product Manager see https://about.gitlab.com/handbook/product/categories/

Hey, I'm Jason - the PM director for this area. I really do appreciate the pings - you can @ me at my username jlenny in issues that are important to you. It's true in general, even for features, but especially for issues a heads up helps us make sure we are prioritizing things in the right order.

You had already been involved in the issue, from what I recall. I also did state my dissatisfaction when it just continued to get pushed back. I get it, bug fixes aren’t glamorous and it’s not fun to work on them, but they still need to happen.

Re: Maturity

#88

> Provides an elevated user experience that customers love as measured by NPS. What's NPS?

Net Promoter Score. Is a score calculated with a periodic survey that tries to determine cohorts of promoters (people who like your product so much that they are willing to recommend it to colleagues) and detractors (people who hate your product so much that they usually talk bad about your product if the opportunity to do so arises.) This is calculated through those surveys you get sometimes that say something along…

Huh, I'm confused how that score would tell you if a particular specific feature/area of the app provided "an elevated user experience that customers love". Any ideas?

Re: Maturity

#89

Earlier quoted context omitted.

We released DAG as an MVC, which helped a lot of people out even in its current state. We do release features here iteratively intentionally, with the idea that feedback will help make future iterations better in unexpected ways compared to if we released a big feature all at once. The items you mention are scheduled for follow-ups in our epic https://gitlab.com/groups/gitlab-org/-/epics/1716 . Your feedback on seque…

Whole this discussion is mostly about how feedback is not taken into account and customers and users are not heard. Gitlabbers keep using this "release early and then let feedback to shape future " mantra, but in practice it is rarely happen or at least doesn't happen quick enough.

It's also an attitude that pushes the cost of wrong decisions to the users, and really it just sounds like an excuse for not spending the internal resources required to do proper designs and quality assurance.

Re: Maturity

#90
I'll add my two cents and feedback:

I like the GitLab flow, and I absolutely love the "Create merge request" button in the issue detail. I miss it dearly whenever I'm working on GitHub, and `hub pull-request` isn't quite the same.

I don't like the code review functions: for example when I'm in the changes tab, where I can both resolve discussions and double-check the code, cycling through unresolved discussions breaks every time and I have to go back to the discussions tab where to check the code I have to open the linked diff in another tab.

I don't like the settings UI, with all those "expand" buttons so far on the right side. I mean, there's even one of those buttons in places where you have only one fieldset worth of settings.

Post reply on HN