drkonqi and outdated software

[Harald Sitter]

On Wed, Nov 19, 2025 at 1:37 PM A. Wilcox <AWilcox at wilcox-tech.com> wrote:
>
> On Nov 19, 2025, at 02:39, Harald Sitter <sitter at kde.org> wrote:
> >
> > Hey!
> >
> > I currently have an MR open to disable crash reporting to KDE by
> > default and would like your input on the matter.
> >
> > https://invent.kde.org/plasma/drkonqi/-/merge_requests/364
> >
> > Essentially we have a problem with users sitting on outdated software
> > versions, reporting crashes, and then getting their crash closed
> > because their version is no longer getting releases from us. So the
> > idea is we have a simple knob to turn on/off reporting to KDE at
> > compile time and leave it to distributions to toggle this as
> > necessary.
> >
> > When this is disabled, instead of getting the regular drkonqi UX flow,
> > the user will get a less integrated flow where they get a notification
> > about the crash that takes them to coredump-gui and then from there
> > they can click a button to go to the bug report url you have defined
> > in os-release.
> >
> > How the knob is used is mostly up to you. You could have it enabled
> > while you ship supported versions but disable it when their support
> > ends. Or just leave it disabled and route all crash reporting through
> > your bug tracker first, upstreaming as necessary.
> >
> > Obviously if you release supported versions regularly through rolling
> > updates or backports you can always enable reporting to KDE.
> >
> > There is also the matter of default-off or on. Any preferences?
> >
> > HS
>
> Hi there Harald,
>
> My personal preference would be to have support for a custom helper
> that can be called by DrKonqi.  This should take a normal DrKonqi
> report as input via stdin, and return 0 on success and non-zero on
> failure (so DrKonqi can say “Thanks, your report is submitted!” or
> “Sorry, there was an issue submitting your report.  It’s at
> [/tmp/drkonqi-report or such] if you want to submit it yourself."
>
> Then the custom helper can report to the distributor, instead of
> just dropping the user in a bug report URL that they may not
> understand, requiring them to sign up (which may be too much effort
> for them), and cause even more frustration.  Or, by default, the
> ‘custom' helper can just xdg-open the bug report URL (or such).

I suppose that would be doable. The distribution would have to supply
the custom helper though, not sure if there is substantial interest in
writing those. On the drkonqi side we only need to add some logic for
invoking it, which is only a couple of lines probably. e.g. see
https://invent.kde.org/plasma/drkonqi/-/blob/4293a88204d9a07407db7d2f1b2189b202f7e756/src/coredump/gui/Patient.cpp#L232

> I also want to ask here for total clarity: does that mean there
> will never be a Plasma LTS release again?  I know that the outcome
> at Graz was that Plasma LTS was being suspended, but I thought it
> was while KDE 6 was being evolved, and it had a chance of coming
> back once things settled down.  My bad if not.

That's actually unrelated, we'd have the problem of EOL to consider in
any setup :) My memory of the discussion is a bit limited but I think
there was a general feeling that LTS wasn't quite delivering and so
for the foreseeable future we are doing ordinary releases instead,
with like a month of maintenance overlap to ease the transition from
one to the next.

HS