Who’s responsible for bug reports on old software versions? – Adventures in Linux and KDE

Skip to content

Nate

FOSS culture, Software distribution

July 19, 2026July 19, 2026

6 Minutes

Consider this hypothetical:

An operating system (OS) ships version 1.5 of a piece of software.

Meanwhile, the latest version of that software is 3.0.

A user on that OS experiences an issue in version 1.5, or has an idea for a new feature. Who should they contact?

This hypothetical becomes concrete due to the existence of discrete-release OSs, like Ubuntu, Debian, openSUSE Leap, and Linux Mint. These intentionally freeze on certain versions of the software they ship for a certain period of time — even if newer versions have already been released upstream of them.

It’s in the news right now because of a recent kerfuffle over in Linux Mint specifically; a developer of GNOME Calendar asked Linux Mint to patch out support links and change the branding, and later followed up with a fairly inflammatory blog post after the issue was locked for understandable reasons.

This saddens me because the miscommunication was preventable, and now a good portion of the discussion surrounding the topic is about tone rather than the topic itself — a predictable outcome of not caring about tone. But I digress.

I think it’s an important topic, so I thought I’d share my take on the situation.

Are software developers responsible?

Software devs wrote the software. The software broke. End of story.

If only life were that simple!

Having been on the receiving end of thousands of un-actionable bug reports about old versions of KDE’s software in discrete-release OSs for issues that were fixed months or years ago (but not backported by the OS distributor!)… I can tell you it’s very frustrating.

But we in the free, open-source software (FOSS) world make our software available via free software licenses; we need to be prepared for OSs distributing our software in ways we didn’t anticipate or aren’t thrilled about, and bug reports from their users. That’s life.

Our solution in KDE is a bot that automatically closes bug reports for versions of Plasma that are out of support, and we may eventually broaden the system to cover our apps and frameworks, too.

It’s not perfect, but it mostly works out. I can tell because most of the new Plasma bug reports I see these days are from users of rolling-release OSs like Arch, OpenSUSE Tumbleweed, and Fedora KDE (which is not truly rolling, but it’s close enough), and I’d say most are actionable.

It kind of stinks for users of discrete-release OSs, who get a robot telling them that the work they just put in to report the bug was useless. But they also benefit from rolling-release users effectively being their free quality assurance (QA). Trade-offs.

Are distributors responsible?

If my car breaks, I blame the car company — not the vendor who sold them the part that broke.

(well, maybe I blame them too if I’m a car nerd, but that’s the exception!)

Ultimately OS distributors are the car company here, assembling the final product. It’s their job to do adequate QA and work with their vendors (upstream software devs) to make sure that final product sparkles.

Of course, a new car costs many months’ salary and includes a multi-year warranty, while most FOSS OSs don’t and are distributed for free. So expectations need to be tempered a bit.

This is where I think communication breaks down. A lot of free-of-charge FOSS OSs advertise themselves really positively, promising the sun, the moon, and the stars. Whereas the truth for many is that they’re assembled by a small team with a shoestring budget (or none at all) from years-old software offered by grumpy developers they don’t have a great relationship with.

Users then don’t understand the full picture of who’s responsible for what, or the level of support they should expect and from whom.

This is the reason why KDE Linux includes tons of qualifiers and provisos in its marketing material. We don’t want to over-promise! It’s a small project built by a small team. I think every piece of free software should be clear about who should use it… and who shouldn’t. Don’t over-promise! It’s a recipe for frustration and disappointment on all sides.

And if you want an OS with professional backing, you’ll likely need to pay for it.

So what’s the solution?

As a distributor, I think you need to sort out what kind of relationship you want to have with the developers of the upstream software you ship.

Do you want to be able to have a distant relationship? Then I recommend abandoning discrete releases and adopting the rolling release approach.

In this model, you take upstream software the moment it’s released — or at least soon afterwards. Then the conflict disappears! Almost all bugs become upstream bugs, and you can direct users to upstream devs without getting any push-back from them. Everything remaining is an issue that you can fix in your OS.

Rolling release OSs...