Consider this hypothetical:
This is a companion discussion topic for the original entry at https://pointieststick.com/2026/07/19/whos-responsible-for-bug-reports-on-old-software-versions/
This is a companion discussion topic for the original entry at https://pointieststick.com/2026/07/19/whos-responsible-for-bug-reports-on-old-software-versions/
10 Likes
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.
Maybe a good reason to have them fill out a version identifier right at the start, so it can tell them before they put in the work of filling out the rest of a bug report. (assuming this is even possible with bugzilla, I’m not familiar with its options for customization)
3 Likes
Me neither. But if that’s possible, it would be ideal. The very first question in a wizard-style workflow could be “What version of the software are you using”?
2 Likes
That is the first question we ask when people come for help in Kdenlive.
– I am having such issue
– What version are you using?
– 22.04.2
– Oh, your using Mint/Ubuntu/PPA packages? Try the Flatpak or AppImage.
Problem solved in most cases
4 Likes
This has raised a question in my head, since I got interested in Linux, I’ve seen mention of backporting this that and the other, mostly in the kernel. How does backporting work, beyond the blatantly obvious that is, what mechanism is used? How does versioning work if you’re dealing with an Ubuntu/Mint type distro?
Maybe more ideal for all software to have a “report bug” action in a common location. KDE apps have it, but Plasma shell doesn’t.
And distros should be able to redirect the bug tracker via a global setting.
2 Likes
That depends a lot on the type of change and how much else has changed between the old and the new version.
Sometimes it could be as easy as a “cherry pick”, a GIT feature to apply a code change directly onto a different version.
In other case it could be as necessary the do the change all over again.
This is also tricky.
If the old version is still getting (bugfix) releases then the backport will eventually be in one and can be picked up by distributions (sometimes they don’t update to the latest bugfixed version).
If it does no longer get releases then the distribution would need to get the source code from the update branch and essentially increase the version of their package independently. This is even less likely to happen than taking the latest bugfix release.
I see, thank you.
Not a bad idea. Maybe we could put a tiny tiny app in the “Help” category in Kickoff?
1 Like
What about those weird middle ground distros like Debian Testing or OpenSUSE slowroll or the like. They are both rolling releases but also a little behind.
How not to make a bug report on old software versions 
4 Likes
Oh jeez, I remember that one now.
4 Likes
You are extremely rude - I want the senior developer immediately 
2 Likes
You must be immediately removed from your position!!!
3 Likes
Was not aware that Karens submitted bug reports.
2 Likes
Can see different POVs…
As a Debian user, I accept that patches will be limited to security issues and waiting until the next milestone release for other fixes or newer versions, or making my own arrangements to find newer packages or appimages. I prioritise stability for the main system and step outside that occasionally.
As a Mint user, or user of another distro targeting or appealing to newbies that’s based on an LTS release of another distro, or as someone who has no background on the wider ecosystem, that might need some spelling out.
So app devs still should have sensible triage processes; e.g. most active project FOSS git type sites seem to have reporting processes where people need to confirm they’re running a latest release. Some software might have links that communicate a version number to a support site when visited, although I’ve never really noticed that or bothered to look in software for links to support sites. I don’t notice many bugs in software, to be honest, mature projects tend not have noticeable ones.
1 Like