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 can still have good relationships with their upstreams, of course. But it isn’t as critical.
Don’t want to be a rolling release? That’s fine. Then you need to work closely with your upstreams.
Communicate your users’ complaints and bugs upstream, help drive fixes, and then ship them. Many software developers already release bug-fix versions in addition to feature versions. If they do… ship them! Don’t ignore them; this will make your upstreams grumpier.
If any of your upstreams release a “long-term support” version of their software, ship that. If they don’t, you can even work with them to create one if they’re amenable to the idea, and help to support it.
This is more work, obviously. So if your team is small, it may not be feasible to do for every piece of software you ship. But you can try for the most important ones: the Linux kernel, systemd, Mesa, Libinput, PipeWire, NetworkManager, BlueZ, udisks, CUPS, and KDE or GNOME.
But that’s the important point: shipping a high-quality discrete release OS is more work than producing a competent rolling release. No way around it.
So a way to make this approach more feasible is to reduce your OS’s scope of concern.
For example, you can delegate app distribution to a third party like Flathub, the Snap store, AppImageHub, etc. This lets you focus on just the base OS and its desktop environment, while apps are rolling, which means they’ll accept bug reports about them. Personally, I think there’s a lot to like about this model.
It also helps if you don’t let the software get too out of date. Up to 6 months old? Your upstreams are likely fine with this, and will accept bug reports. 12 months? Mostly fine. 2 years? That starts to get painful for your upstream developers if users are still reporting bugs to them. 3 year or more? Very painful. We pretty much have to direct them to their OS vendor.
What’s not the solution?
Package 2+ year-old frozen releases of as much upstream software as you can, and then ignore the upstreams, their bug-fix releases, and their complaints about this.
This is the worst of all worlds!
- Users get outdated software that’s full of bugs and security holes fixed long ago
- Software developers get un-actionable bug reports from angry and confused users
- Distributors get frustrated communications from software developers that damage or destroy important relationships
Please don’t do this. It isn’t sustainable over time, and will cause a leak of the most desirable users who make an active choice to use your OS.
How do I know this?
Well, I don’t, but I can make an educated guess based on some of the few statistics we do have. A big one is the OS market share on ProtonDB as compiled by BoilingSteam, which counts Linux gamers:
In 2019, the “rolling and rolling-ish (e.g. Fedora)” OSs made up a little over 36% of the total users.
In 2026, they’re up to 71%.
This isn’t everyone, of course; only gamers using ProtonDB. But still, it’s quite a change. Clearly gamers believe rolling-release OSs cater to their needs better than discrete-release OSs do.
So, if you ship a discrete release OS, and you don’t want to or can’t switch it to a rolling or semi-rolling release cadence, please please please work with your upstreams! As a (sadly now only merely occasional) upstream KDE software dev, I can tell you my favorite distributors to work with are the ones who engage with KDE and help get problems solved. It’s a lot of fun when all parties focus on problem-solving.
Adventures in Linux and KDE 
Well said, in the end, diplomacy and working together wins. I have been frustrated multiple times by users of some LTS distros sending bug reports for old software, but it’s not really their fault, they may not understand that distinction.
What I hope is that upstream distros would patch “report bug here” urls in apps to point at their bug report system. I don’t know how much it would help in the end, but it would be the right thing to do, imo.
LikeLiked by 1 person
TheEvilSkeleton is just looking for yet another internet fight. He does that every other week.
Just don’t pay attention to those drama queens.
LikeLike
arent you a registered child r_pist? https://www.offenderradar.com/offender-details/jeremy-clayton-bicha-of-florida-176493
LikeLiked by 1 person
Yikes. I had no idea.
Jeremy, that will have to be your last comment on this blog.
For everyone else, that will also be the last comment about either Jeremy Bicha or Bryan Lunduke. Let’s keep the discussion here to the topic at hand, and not let it turn into a circus.
Thanks, everyone.
LikeLike
there’s nobody named evil skeleton in these comments so I’m confused what that mention was about
LikeLike
The Gnome Calendar creator who’s upset with Linux Mint goes by that moniker.
I understand their frustration because a bug report about a piece of software from over a year ago is often not going to be particularly relevant to the current state of the software. Simultaneously, as a user in most cases I don’t want my software to randomly change every few weeks or more, unless there’s a specific issue that’s been fixed.
LikeLike
Yeah, this a case where no one is really right; it’s a conflict of desires and preferences.
With my software dev hat on, I totally 100% sympathize with wanting users to always be using the latest version. Or rather, let me clarify: I want users who report issues to be always using the latest version.
So that’s probably where the point of compromise lies. If you’re using an old version, then upgrade first to verify the issue is still present in the newer version, or report issues to the distributor, or don’t report issues.
Of course, communicating this and nudging users on old versions towards it will not be a simple task!
LikeLike
Game software is as transient as it gets.. A very poor example.
However, if I get burnt by some software that doesn’t get support after 3 years, I drop it. It’s that simple. The distro should too – if it’s costing them too much grief. I’ve done this with proprietary software.
I did like the apps that I dropped but having to move to a different packaging system or distro (or risk losing data or time (aka money) converting to the latest and greatest on a frequent schedule) is a definite negative discriminator.
Having to require a rolling distro or a “close” relationship between distros and the *upstream* curator(s) is not going to work. The current case of record is about “Calendar” software and a 6 month turn-around in versions? It’s so mundane an app that I’m not going to bother to really dig into the details. But, I agree that 6 months is a clear indicator that the software is likely to burn and the curator is not going to give a flying fig about developing relationships..
Anyway, if the *upstream* curator somehow wants the software to grow, they may want to consider other use cases besides games and transient software.
LikeLike
The rolling release that the demographic of “people who use ProtonDB” used applied to all software on their system, not just games.
LikeLiked by 1 person
I agree with you, Nate.
I stopped using Ubuntu and Fedora (yes, the Fedora mentioned in the article) for exactly that reason, and I’ve been using KDE Neon on all my PCs—both at home and at work—for six years now.
At work, my colleagues suggested I install Debian on my workstation, but I turned them down. I can’t stand the idea of not having up-to-date software, unless I’m forced to use Snap, AppImage, or Flatpak. The best integration with the underlying operating system comes from its official packages.
LikeLike
Many people enjoy stable distros for smooth experience knowing softwares have been very well tested. Rolling distros on high availability servers is a pain for example.
It depends of the use case, if users are expecting things to break, or if they need to ensure their favorite programs will behave exactly the same for years (like most companies want, even if it could create massive technical debt).
It seems that Gnome Calendar have many reports from social networks, forum and direct messages (since many Gnome contributors are heavy users of theses). It’s certainly a good mean to get more bug reports but it’s time consuming, and certainly more frustrating you cannot help.
As for the drama, Mint relies on (outdated) Debian/Ubuntu package for Calendar (and dynamically uses their libAdwaita fork to add themes) and doesn’t want to deprecate it to prevent it to disappear from repo (and be definitely outdated for users that have installed it), or continually patch Gnome Calendar (and maybe many other Gnome apps) since as Clement Lefebvre stated it should be patched in Debian and Ubuntu (since it’s not related to Mint but all distros based on stable Debian and Ubuntu, like Zorin, Elementary, Pop!, Linux Lite and hundreds of others, Mint is just one of the most popular one).
LikeLike
Is that true, though? Discrete-release OSs don’t generally make this promise. Some imply it, and users assume it, but if you think about it, it’s an impossible thing to assure for an OS with any reasonable complete software library.
For example, Debian has over 70,000 packages. There isn’t enough labor in the universe to test all of these packages against every other combination of packages. You can use automation to test that they compile and install, but to test that they work as intended? probably impossible, even if you unleashed LLMs on the task.
LikeLike
(reply to Nate)
Typically, if software has good integration tests, “serious” distributions will *always* run them. To be fair, this applies to rolling releases as well, but it makes it a bit more realistic to have a baseline for everything working as intended.
But you’re right, testing as in actual usage, takes a lot of more effort, and is naught impossible. In Debian at least, packages are dropped to testing and if no bug reports appear from active users, they move to stable. So the chances of someone having ran it and uncovered at least the major issues are bigger.
LikeLike
I guess some things like links to support channels would best be supplied at build time instead of somewhere in code.
Then every packager would be aware of the need to supply their own, e.g. support lies with the distributor.
If the app team packages themselves, e.g. for Flathub, it would point to app channels.
If the Debian/Fedora/… team packages for their repo, it would point to their channels.
If the chain becomes longer, e.g. a “spin” of base distribution, that link in the chain would provide their channels if they replace their upstream’s package.
In the case linked to this would mean Mint is responsible for their GNOME Calendar as long as they build their own version.
Not sure requiring distributors to rebrand is such a good idea though.
Basically your app would “disappear” from all distributions and be “replaced” with dozens of clones.
Your official version, e.g. on Flathub, would then be in direct competition with all those clones.
Hopefully your version has more features and fewer bugs but it could also miss out on a lot of integration. Might really depend on how stand-alone your product is meant to be.
LikeLike
Some kind of automatic assignment of the bug report URL is probably a good idea; the only question is how.
Doing it at build-time would require more labor, and I imagine produce some grumbling.
Another option is to have the software itself swap out the URL for the distro’s own bug report URL, which is known due to being set in /etc/os-release. Of course how does the app know when it’s past its EOL date? To do that without phoning home would require the app to predict its own future. Which is possible for apps that release regularly on a schedule, at least.
LikeLike
I was thinking about doing this as build time to make this a build decision, adding awareness on part of the builder about taking responsibility.
I.e. if Debian builds it then they add their channel info.
Even if a Mint user (LMDE) installs from the Debian repo then this is where reports should end up.
If Mint builds themselves and users install that version, then they become the designated support supplier.
But a standard config might also work
The EOL date is likely specific to each repo/store and also how to handle it.
LikeLike
GCC and similar GNU software have a –bug-report-url configure flag or similar. I think it should be up to the distributor to decide whether they’ll process bugs first to deal with possible downstream breakage before bothering upstream (very frequent regardless of release cadence!), or they work closely enough with upstream to direct them to the upstream tracker directly
LikeLike
“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.”
I know it’s a bugbear of mine, but I think this traces back to Ubuntu. Before Ubuntu, most distros did not have polished front pages making bold claims about what wonderful, polished, end-user friendly OSes they were, and massaging away the complex underlying reality. (See the Fedora front page circa mid-2004: https://web.archive.org/web/20040612084620/http://fedora.redhat.com/ ). Then Ubuntu came along, and had one, and ate everybody’s lunch; so one of the lessons a lot of other distros learned was “we should have a front page saying what a wonderful operating system we are for everybody”.
OK, it’s not quite that simple. The earlier commercial, end-user focused distros like Mandrake also had a clear motivation to sell themselves as great, polished end-user OSes, and they certainly tried to. But they did also have a clear motivation to try and keep users within their own community space (so they could sell them support / fixes), and because they had to try and make money, they just didn’t have the reach that Ubuntu had when it showed up. So the impact was muted.
LikeLiked by 1 person
This is a follow up to that stream of thought Nate. (Hello, your friendly Inkscape developer here)
Tested means “users have used this a lot”. So user testing. Inkscape depends on a lot of user testing since our automated testing is extremely poor (working on it!) and this is its own bag of pros and cons.
What “well tested” does not mean is “well fixed”. Which is the core of the point of the conflict. The packages have indeed been very well tested. But haven’t actually used that testing to deploy fixes. Because the fixes went upstream, those went into newer versions and those versions aren’t available here.
This is actually one of those fun logic brain puzzles. Because once you see the error, it becomes extremely obvious where the double counting happened. 😅️ The promise was just a positive spin on the exact negative problem expressed.
LikeLiked by 1 person
Don’t understand anyone’s response in this whole drama.
In the CMake upstream we mark issues as duplicate/fixed and move on. A few confused Debian stable users don’t harm us at all. It would need to be dozens of issues, daily, to become a problem worth addressing.
gnome-calendar seems to have received a <500 issues in its entire lifetime. We clear that every six months or so. Dozens of those end up being distro-packaging related. They take a few seconds to triage and then you’re back to productive work.
LikeLike
I reckon part of your experience is due to cmake being a developer-oriented build tool. You don’t get to deal with the vagueness of end-user reports, and most issues can be exactly reproduced by running the same command or cmakelists.
End-user projects tend to deal with race conditions, compatibility with other apps, file formats and web services, integration and behavioral differences depending on OS or desktops, behavioral issues depending on input methods, dragging windows and elements around, copy/paste, etc.
Your doubt that it may be a bit overblown is somewhat valid though, I have doubts myself, but it’s very clear that things could be better.
LikeLiked by 1 person
@Vito
Ultimately this is my experience in KDE as well — but it may also be our bug bot doing its job! 😁
LikeLike
I fundamentally disagree with the angle that TheEvilSkeleton is “looking for a fight”.
Clement Lefebvre’s comments on the GitLab issue couldn’t be more evasive and dismissive of the simple request GNOME devs made in good faith: point the “Report an issue” link in the About box of GNOME Calendar to Mint’s issue tracker, if Mint wants to keep shipping old versions.
That’s it. One link and this could all have been avoided.
Instead Clement chose to be dismissive with bad faith arguments. He kept misinterpreting the GNOME devs’ intent on purpose while completely ignoring the original request. He constantly shifted of the goal post and dodged taking responsibility for Mint’s choices. And when GNOME devs clearly got tired of having to re-iterate their points over and over again, because Clement would just ignore them again and again, he insists that the devs are being unreasonable and childish; like he isn’t all “lalala I can’t hear you”. His strawman arguments about “you chose the wrong license, sucks to be you, deal with it” just tops it all off. Like publishing software under a FOSS license somehow gives him a free pass to spit into upstream’s face.
From where I’m sitting, this is a distro adding to the burn-out of FOSS devs, and that rightfully earns them the moniker “hostile”.
LikeLike
I don’t think that Hari (TheEvilSkeleton) was looking for a fight, and I didn’t write that, or even imply it. I only objected to their tone and approach. The actual content of their complaint is something I almost entirely agree with. And I think with a more diplomatic approach, it might have been possible to avoid the conflict and get something useful done. Instead, it turned into a fight that Hari appears to have lost, since I don’t see Linux Mint making the requested change.
Yes, this is tone policing. That’s because I think tone is important! Not caring about it provokes avoidable fights and causes everyone to dig in their heels.
LikeLike