Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maturity

about.gitlab.com

Post reply on HN
Print view View original

61–70 of 127 posts

Re: Maturity

#61

Post by sytse »

waltera wrote: post #55
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.

We had a very similar experience with Gitlab too. Our teams evaluated Gitlab for a year before completely migrating away from it (to Github Enterprise for SCM, Confluence for wiki, YouTrack for issues and TeamCity for CI). Not a single team (out of 20) was happy with the overall performance (and especially the performance of code search). As far as wiki is concerned, Confluence's UI has its own share of issues, even…

Code search is not good at GitLab.com at the moment. We're working to enable ElasticSearch for GitLab.com to improve the situation https://about.gitlab.com/2019/03/20/enabling-global-search-e...

Re: Maturity

#62

Post by sytse »

KaoruAoiShiho wrote: post #47
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…

A wiki's not the same usecase as static site, a static site is for marketing and wikis are for project management. I mean maybe people would use it if it weren't crappy? I would've been happier if the wiki didn't exist and I didn't invest time into wrangling it. ATM it's just a frustration. It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of interna…

I looked up our wiki direction and the ideas is to allow WYSIWYG collaboration, see https://about.gitlab.com/direction/create/wiki/

I'm surprised that this wiki bug that two people here mention has only one upvote https://gitlab.com/gitlab-org/gitlab-ce/issues/48641 I'm not sure if the complaints are over multiple issues, if the wiki doesn't get a lot of usage, or something else is going on. The bug sounds legitimate.

Re: Maturity

#63

Post by jl-gitlab »

sytse wrote: post #19
Operyl wrote: post #18

Earlier quoted context omitted.

So, can you shed some light on how the actual prioritization works? There are some bugs, one specifically I've mentioned elsewhere, that just get infinitely shoved into the void.

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.

Re: Maturity

#64

Post by ulrikrasmussen »

pritianka wrote: post #39
mikepurvis wrote: post #29

Earlier quoted context omitted.

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 ab…

I would much rather have fewer features which work well. For example, until recently there was a restriction that jobs could only run in parallel if they were defined in the same "stage", and no two stages could have running jobs at the same time. This means that a job whose dependencies were met could not necessarily be started because it belonged to a later stage (and jobs cannot depend on other jobs from its own stage, more on that later).

GitLab then introduced another way of specifying dependencies using the keyword "needs" ("dependencies" was already taken by the half-baked implementation). This allows jobs from multiple stages to run concurrently, as you would expect. However, you are still required to shoehorn your jobs into stages, even though they should be completely deprecated by now. Worse, the restriction that jobs cannot depend on other jobs from the same stage still remains. On top of that, the visualization of a pipeline pretends that the new way of specifying dependencies does not exist, so all the arrows between the jobs are meaningless.

I would much rather have had a proper implementation of the simple, more general approach, than having to deal with the legacy of a hacky and half-baked solution.

Re: Maturity

#65

Post by rossmohax »

enraged_camel wrote: post #53
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.

My impression is the opposite. Compared to Github, Gitlab is simply phenomenal, especially the UX. It's honestly one of the few pieces of software that I truly enjoy using every day.

Enabling "AutoDevops" on ALL existing projects and wasting runner minutes people payed for is indeed "phenomenal".

Re: Maturity

#66

Post by rossmohax »

sytse wrote: post #19
Operyl wrote: post #18

Earlier quoted context omitted.

So, can you shed some light on how the actual prioritization works? There are some bugs, one specifically I've mentioned elsewhere, that just get infinitely shoved into the void.

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/

PM optimizes for his own KPIs, which are at exec level. Given the history of ignoring bugfixes and becoming famous for it, clearly direction leadership sets gives no incentive to fix customers problems.

Re: Maturity

#67

Post by jl-gitlab »

ulrikrasmussen wrote: post #64
pritianka wrote: post #39

Earlier quoted context omitted.

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 ab…

I would much rather have fewer features which work well. For example, until recently there was a restriction that jobs could only run in parallel if they were defined in the same "stage", and no two stages could have running jobs at the same time. This means that a job whose dependencies were met could not necessarily be started because it belonged to a later stage (and jobs cannot depend on other jobs from its own s…

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 sequencing or how we are approaching the different improvements is more than welcome.

I would have loved for the feature to be useful for you too in the MVC iteration, and I'm sorry it wasn't. We are still working on it, though, and I hope that it does become valuable for you also. In the meantime you should still be able to use GitLab in the same way you always have - let me know if you're having trouble running pipelines without the DAG.

Re: Maturity

#68

Post by milofeynman »

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.

They love producing public facing verbose process documents... At first I thought, oh these are some neat ideas, but the more that they produce, the more I wonder how they get anything done with so much (verbose) process.

Re: Maturity

#69

Post by ulrikrasmussen »

jl-gitlab wrote: post #67
ulrikrasmussen wrote: post #64

Earlier quoted context omitted.

I would much rather have fewer features which work well. For example, until recently there was a restriction that jobs could only run in parallel if they were defined in the same "stage", and no two stages could have running jobs at the same time. This means that a job whose dependencies were met could not necessarily be started because it belonged to a later stage (and jobs cannot depend on other jobs from its own s…

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…

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 users.

Also, this is just a single example that I pointed out to outline what I think is a problem with the whole development culture around GitLab, which puts too much focus on releasing early, and too little focus on quality assurance. Of course, you shouldn't spend years perfecting the next release, but you release too many features too early for my taste.

Re: Maturity

#70

Post by antonvs »

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…

> The current state of the wiki isn't great but we're also not seeing a lot of people care about it.

That may be because people who do care use a different product. Be careful you don't metric your way to extinction.

Post reply on HN