Maturity • Hacker News Board

Re: Maturity

#31

Post by bureaucrat » Tue, Sep 10, 2019, 1:13 AM UTC

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 for buttons PLEASE. Github is sort of flat and their interface is great with adequate use of contrasts.

https://imgur.com/a/EIlV7ri

Re: Maturity

#32

Post by sytse » Tue, Sep 10, 2019, 1:13 AM UTC

Operyl wrote: post #26

sytse wrote: post #24

Earlier quoted context omitted.

Existing customers tend to prioritize stability (fixing bugs) over new features. Please note that even if you're not a customer our issue trackers are open so you can @mention the Product Manager to help them understand the severity and help to diagnose and fix things if you're so inclined.

As seen in https://gitlab.com/gitlab-org/gitlab-runner/issues/4029 , a few people did show frustration, and why. And then began the never ending push back after push back.

I agree this issue hasn't been prioritized as high as it should. I meant to indicate that with "This bug took too long to fix." but I should have said it took to long to schedule.

We concluded the same internally recently and hence the focus on bugs and wider community contributions in 12.4. We overly focussed on getting the DAG https://docs.gitlab.com/ee/ci/directed_acyclic_graph/ and Merge Trains https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipeli... out the door and missed a bad bug, we're sorry.

Re: Maturity

#33

Post by jrochkind1 » Tue, Sep 10, 2019, 1:18 AM UTC

> Provides an elevated user experience that customers love as measured by NPS.

What's NPS?

Re: Maturity

#34

Post by flocial » Tue, Sep 10, 2019, 1:22 AM UTC

Gitlab is a great product for self-hosting a GitHub-like service and I'm grateful for its existence. Having said that, I'm not a big fan of their bait and switch approach to feature creep. Every time I try to update our GL I end up in a world of hurt.

No straight upgrade path when you skip major-ish releases. I end up wasting a day sifting through cryptic issues and docs from vague error messages.

Suddenly can't commit because now my branch is "protected" and failed a deploy pipeline I didn't implement courtesy of GL's "vision".

Not to mention all this comes at the cost of increased complexity and resource usage.

I wish there was a "thanks but no thanks" setting to keep our instance the bare minimum without having to adopt features whole hog every time they get inspired to incorporate the next "big" thing.

Re: Maturity

#35

Post by jrochkind1 » Tue, Sep 10, 2019, 1:23 AM UTC

sytse wrote: post #17

KaoruAoiShiho wrote: post #8

I was sucked in by Gitlab's feature list and marketing. But holy shit so many things are half assed and so many features are buggy and broken. Like their wikis would sometimes just straight up delete text and their webhooks would break images. I started a bunch of issues but they really have no chance of getting fixed anytime soon. Just shows how different your impression of something is after actually using it.

The wiki is GitLab should not delete text, please file a bug if you had dataloss. The current state of the wiki isn't great but we're also not seeing a lot of people care about it. Many people are switching to static websites. Therefore we're not investing to get the wiki better than the current state of a half circle. BTW We've recently measured experience baselines in GitLab and we agree we still have a lot of work…

I'd rather have no (eg) wiki feature at all then have a half-assed one.

Because _if_ I feel like the feature might be useful, I'm going to try to use it, and invest time in trying to use it, and only then find that it's not reliable or well-polished after all. The more such features there are, the more chance I'll spend at least some time being frustrated by at least one of them.

One of the joys of really well-polished software is that if the feature wasn't worth doing right (and not every feature is!), it simply isn't there at all, so if a feature is there I can count on it being well-thought-out and well-executed.

Re: Maturity

#36

Post by colechristensen » Tue, Sep 10, 2019, 1:24 AM UTC

sytse wrote: post #20

CameronNemo wrote: post #7

Earlier quoted context omitted.

The GitLab team will readily admit that they have a breadth first policy. This gives transparency for that policy, and does not change it.

That is still our policy but we recently added something to https://about.gitlab.com/company/strategy/#breadth-over-dept... that might be relevant: "So breadth over depth is the strategy for GitLab the company. GitLab the project should have depth in every category it offers. It will take a few years to become best in class in a certain space because we depend on users contributing back, and we publish that journey o…

My first experience with GitLab, several years ago, felt like it needed this policy. I actively didn't like it, and did not see the point or added value.

Now my experience is exactly the opposite. I like all of the things GitLab does, it is an obvious and significant value add but ... when I have experimented with it in a home lab and elsewhere there were several things which gave me pause, and I've seen the same expressed elsewhere which alleviates doubts I may be wrong.

Now I'm in the position where I like something and hesitate to recommend it worrying that the details will make my life more difficult and my users' lives more difficult and not less, not because of missing big features but because of quality and depth, as you call it. Maybe it's the right thing for your business to go for breadth even for years longer and seek depth in the future to solidify your position. But for now, as a potential user, GitLab might not be right for me, which I think is unfortunate.

Re: Maturity

#37

Post by whoisjuan » Tue, Sep 10, 2019, 1:24 AM UTC

jrochkind1 wrote: post #33

> 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 the lines of "From 1 to 10 how likely are you to recommend X product to a friend or a relative".. or something like that.

Re: Maturity

#38

Post by buildzr » Tue, Sep 10, 2019, 1:26 AM UTC

bureaucrat wrote: post #31

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…

> even their official server.

Annecdata, but to me it seems more like their official server is the slow part, I run my own instance and it seems pretty snappy.

Re: Maturity

#39

Post by pritianka » Tue, Sep 10, 2019, 1:27 AM UTC

mikepurvis wrote: post #29

sytse wrote: post #17

Earlier quoted context omitted.

The wiki is GitLab should not delete text, please file a bug if you had dataloss. The current state of the wiki isn't great but we're also not seeing a lot of people care about it. Many people are switching to static websites. Therefore we're not investing to get the wiki better than the current state of a half circle. BTW We've recently measured experience baselines in GitLab and we agree we still have a lot of work…

Perhaps an argument for focusing on doing a few things well? I work for a GitLab shop, but we don't use the bugtracker (Jira) or wiki (Confluence), we mostly don't use the CI (Jenkins is just more flexible), and we definitely don't use the container stuff. We currently do use the review workflow but at various points have considered moving to a different tool for that as well. So yeah, we would have been fine with a…

Hi there! Just wanted to add my two cents here. Just like you choose to use SCM and workflow review, we have a lot of other users and customers utilizing different permutations and combinations of the various stages. Over time, various stages all move toward maturity, some faster than others. I know this is a different model than most software companies and it has its downsides. But the net positive is that we are able to provide an increasingly unified experience for DevOps. Note that at other companies the same thing happens except they market different stages as separate "products". They gain on the marketing but lose on the ultimate user benefit (again, IMHO).

Re: Maturity

#40

Post by coenhyde » Tue, Sep 10, 2019, 1:28 AM UTC

bureaucrat wrote: post #31

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.