To be honest, I haven't found Sentry to be that useful in its current
implementation. The primary issue is that it represents a second source
of truth for where crash reports live. As a result, developers who
already struggle to notice Bugzilla-based crash reports have to look in
a second place, further diving their scarce attention. I haven't seen
evidence of people regularly interacting with it or looking at its
crashes beyond the excitement of the initial rollout, so now it's
largely just a new graveyard of issues being ignored due to insufficient
developer time.
I think Sentry could make sense to keep if it was implemented for us
more as a kind of automatic symbolication service that can take a bad
backtrace, add debug symbols, retrace it, and then pass *that* off to
DrKonqi so that the resulting Bugzilla ticket is guaranteed to have a
*good* backtrace in it. That's a real problem we currently have that
could benefit from being solved in a targeted way.
If we can't or don't want to do that, then Sentry might make sense if it
were possible for us to bypass the "multiple sources of crash truth"
issue by completely disabling Bugzilla for crash reports and migrating
old Bugzilla crashes into sentry. But Then we'd run into the new issue
that Sentry doesn't permit discussion with the person experiencing the
crash to ask for more details if needed. This isn't always needed, but
it sometimes is. Sentry also isn't integrated into our issue priority
tracking system in Bugzilla, but that's a more minor issue.
Nate
On 6/1/23 04:35, Harald Sitter wrote:
Hey,
We've had almost a year, albeit in a super limited capacity for git
builds, with sentry (https://errors-eval.kde.org) and we should
probably render a final verdict on the evaluation.
Did you like it?
What could be improved?
Should we move ahead with a more permanent setup?
The overall game plan would be to have drkonqi ask the user to opt
into automatic crash submission when they open drkonqi so we get close
to all crashes (the ones caught by kcrash) automatically filed into
sentry from then on out. To increase exposure of this feature I'd also
like to glue it into the feedback KCM but I'm not yet sure if it
should be a separate setting or linked to the regular feedback
categories, the former sounds more accessible. The current bugzilla
based workflow would still be available for when the user actually
wants to write a description.
(previous discussion: https://markmail.org/thread/6y5paczdposz3aoj)
HS
