Hacker News Reader

Comment by sytse | Hacker News Reader

This bug took too long to fix. We are not happy how we prioritized the last few releases for CI. In 12.4 we'll focus on fixing 8 of outstanding CI bugs https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...

View on HN

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/

So, the unfortunate reality of prioritizing customer wants like this is that you're always going to focus on big shiny new features, and not quite so much the smaller (while still important) bug fixes that really need consideration I feel. I felt like I got shoved into a black hole, and it does not inspire faith in your product anymore. Even if I did become a customer, which I was seriously considering before this, we're going to be "too small" to make a dent compared to your bigger customer base.

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.

Not a GitLab user, but I'm deeply impressed with your openness in handling issues on this thread.

I've always appreciated how open he is, I just wish it never came down to having to flag him down on Hacker News to get something properly fixed (although, I appreciate that is still something I can do).

Hi - just wanted to confirm that this issue has been addressed and will be included in our 12.4 runner release.

MR: https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...

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.

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.

Reply on news.ycombinator.com