Currently DrKonqi reports crashes for versions that are no longer supported by KDE. (Eg: https://bugs.kde.org/show_bug.cgi?id=501915). Which immediately get closed by the Bugzilla bot. Instead, maybe DrKonqi can give a hint what to do instead (report to the distribution etc..).
The problem is that what is supported differs from product to product. Someone would have to maintain a comprehensive list of what is and isn't supported. And frankly I don't see that happening - it's already not getting updated half the time for plasma. There is also the question if it is worth the code. What does the user gain by drkonqi refusing to report the bug? They'd not have to create a bugzilla account. That's all, no?
Letting them create a new account (normal people hate this!) only for the bot to say "lol git good update your system n00b" does feel a bit Kafka-esque!
True but that is the distros doing more than ours. The problem here is that doing this differently comes at considerable code cost to us when it's really the distro that decided to ship outdated software and the user is having a miserable time because of that. I am not sure the useless account creation is the big problem when discover is crashing every time the user clicks on it. This goes beyond drkonqi even. It's also the bug report link in the help menu for example that lets users report bugs from garbage versions. The low budget approach is to simply have drkonqi's mainpage show a variant of the bot's message on every distro that hasn't been explicitly allowed to report bugs (which is pretty much everything except for arch, fedora, neon, tumbleweed, and based on these). i.e. "disable" drkonqi on slow distros. Whether or not that is entirely fair I don't know.
It sounds like that's more or less the same thing as what's being proposed here, just in a different form. It's tricky though. After a Debian or Kubuntu non-LTS version is released, bug reports from their users will be useful and actionable for six months, maybe a year if we're generous. After that, they become time-wasting noise. This is true even if the Plasma version they're using is technically "LTS", because by that point all of us have pretty much started to ignore the LTS Plasma release too. And of course Gear and Frameworks have no LTS releases in the first place. We could perhaps have a time-based lockout for these distros. And I also think we could cancel the idea of the Plasma LTS release; it's always been a broken promise.
(In reply to Nate Graham from comment #2) > Letting them create a new account (normal people hate this!) only for the > bot to say "lol git good update your system n00b" does feel a bit > Kafka-esque! Agree. The user takes the time to report a bug, download debug symbols, write a description, check for duplicates (well .. sometimes), create an account ... just so the bug report gets auto closed without any human interaction. That doesn't seem fair. If there is enough information for the bug to be auto closed, there is enough information to handle it properly (Eg. report to the distribution instead, or install a flatpak or whatever should be done instead.) (In reply to Harald Sitter from comment #1) > The problem is that what is supported differs from product to product. > Someone would have to maintain a comprehensive list of what is and isn't > supported. And frankly I don't see that happening - it's already not getting > updated half the time for plasma. I don't see this as a problem. Not all projects need to opt in. But if its handled by the bugzilla bot it should also be handled by drkonqi. > There is also the question if it is worth the code. Thats the question. I think so. If you disagree I am not upset if you close this bug report. (In reply to Nate Graham from comment #4) > It sounds like that's more or less the same thing as what's being proposed > here, just in a different form. > > It's tricky though. After a Debian or Kubuntu non-LTS version is released, > bug reports from their users will be useful and actionable for six months, > maybe a year if we're generous. After that, they become time-wasting noise. > This is true even if the Plasma version they're using is technically "LTS", > because by that point all of us have pretty much started to ignore the LTS > Plasma release too. And of course Gear and Frameworks have no LTS releases > in the first place. > > We could perhaps have a time-based lockout for these distros. And I also > think we could cancel the idea of the Plasma LTS release; it's always been a > broken promise. Afaik there are currently no Plasma LTs versions planned. Maybe that will change with whatever the stable version of KDE Linux does. Anyway this question seems out of scope for this issue. (You probably should discuss this in the Plasma sprint instead.) Sorry for the short response, but I hope this clears it up. If not, I can explain it in more detail.
> We could perhaps have a time-based lockout for these distros. How would that work? We don't know when a given binary was released :|