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.
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.
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.
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 maturity page that's linked to in this discussion is actually part of how we are trying to improve our communication around that. This is more at the stage and category level, but features have a maturity level as well and it's worth us reflecting on how that can be made more clear.
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.
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.
Hi! GitLab employee, first of all thank you so much for the detailed feedback! It's part of my job to relay feedback and make customers feel heard, so I'll talk to my team on ways to improve (you can see my job description here if you want: https://about.gitlab.com/handbook/marketing/community-relati...)
As per your second point, and this is speaking personally and not really officially, I do think our feature goal has been historically a bit too ambitious (although hopefully transparently so: https://about.gitlab.com/company/strategy/#breadth-over-dept...) seeing as how we're barely out of the startup phase. But we have had a big hiring push this year and have almost tripled our headcount (which did introduce growing pains of it's own lol). Once we've stablilized a bit, we will be able to dedicate more resources solely on maturing features.
I hope this doesn't come across like making excuses, these are just my observations as a user-turned-employee. I will take your feedback about not being heard into consideration though so we can improve on that!
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.
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.