[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: sentry evaluation
From:       Sharaf Zaman <shzam () sdf ! org>
Date:       2023-06-02 1:15:03
Message-ID: 877csmzmiq.fsf () sdf ! org
[Download RAW message or body]


Hi!

Nate Graham <nate@kde.org> writes:

> 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 looking at Sentry as just another tool to get reports is a wrong way to
look at it (: It should be more like a tool to look at reports which *most*
people are facing, in this case crashes. Sentry isn't currently implemented in
Krita, but on Android we have similar reporting, thanks to google play and it
has helped me a lot to detect crashes in our beta (most people never report
them!). Similarly it has helped me ignore the obscure error that 0.001% of the
user space gets on their out of ordinary device (and you have no idea a crash is
obscure from bugzilla). In that sense sentry is something very similar and could
be a great metric to direct your attention at issues rather than a distraction :)

> 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.

I would absolutely love if sentry could also symbolicate from binary factory
artifacts, but I know it can be difficult!

>
> 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


[prev in list] [next in list] [prev in thread] [next in thread]