Towards Excellent Defect Management

[Albert Astals Cid]

El dimarts, 14 de setembre de 2021, a les 17:23:01 (CEST), Harald Sitter va escriure:
> For many years now I've been unhappy with both the quality and volume
> of crash reports we get for our software. The barrier for crash report
> submissions is incredibly high because we've never really had tech to
> help elevate "insufficient" reports to become sufficient, outside the
> client on which the crash occurred. Out of the very few people that
> might want to report a crash even fewer will get beyond the first set
> of questions from drkonqi, once they've managed they still have to
> fight with their distro for debug symbols and quite possibly lose, and
> even if they win there is a good chance the report will either get a
> "this isn't very useful. install more symbols" comment or get marked
> as dupe. Meanwhile we are spending our days looking at duplicated
> crashes, or finding the right blurb to copy paste to ask for a better
> trace, or try to find out why software crashes that hasn't actually
> crashed for a year because the bug had already been fixed in the
> meantime.
> 
> We are wasting our users' time. We are wasting our time. This waste
> needs to stop.
> 
> The good news is that we have all the technical building blocks to fix
> it today. In fact, it's even getting better in the future still. All
> it takes is a bit of code and a bit of flexibility on our part.
> 
> A while ago I started looking into improving the drkonqi experience.
> Specifically: submitting crash reports into a purpose built crash
> tracking system rather than a bug tracking system. The advantages are
> kind of obvious and ranging from server-side de-duplication to
> server-side retracing. I've spent many afternoons reading up on and
> poking demo instances of every somewhat suitable software I could
> find, and Sentry looks like the best option for what we need. It is
> practically free software as far as we are concerned, scales
> tremendously, has systems for server-side deduplication, server-side
> cross-distro/platform retracing (which might also help with some of
> the open questions of richer tracing for windows and android), data
> scrubbing (what with privacy concerns), client and server-side tags,
> can try to figure out when a crash first appeared if supplied with
> commit data, can track the quality of specific releases, when a given
> crash was fixed, health reports, performance tracking, warning rules,
> health report emails, ... I've been playing with it for a month and
> still find amazing new things!
> 
> One of the best things about Sentry is that it has native support for
> debuginfod, enabling us to get debug symbols directly from
> distributions, solving the entire cross-distro aspect of crash tracing
> in just about the neatest way possible. We get the (incomplete) trace
> with lots of metadata, and Senty then uses the metadata to resolve the
> symbols through the distros' debuginfod instances to give us a
> complete trace.
> 
> Even better: with relatively minor adjustments to drkonqi we could use
> it right now and get immediate advantage of server-side retracing! I
> already have a blob of prototype code for drkonqi that piggybacks
> Sentry submission onto the existing code such that we can have both
> bugzilla and Sentry.
> 
> I am proposing that we roll out a Sentry instance for testing so we
> can see if we want to fully embrace it.
> 
> You can get a general sense of the features at Sentry's demo instance
> https://sentry.io/demo/sandbox/
> Here's a code dump for drkonqi
> https://invent.kde.org/sitter/drkonqi/-/commits/work/sentry

The description of all the things it can do sound excellent :)

Cheers,
  Albert

> 
> HS
>