Error tracker

Registered by Matthew Paul Thomas on 2011-05-10

This blueprint has been superseded. See the newer blueprint "Crash Database" for updated plans.

Microsoft, Apple, and Mozilla have dedicated crash tracking systems, separate from their bug trackers. This has multiple benefits, when compared with Launchpad and apport:
- people don't need a sign-on account, of any sort, to report crashes
- developers aren't spammed with e-mail notifications about duplicate crashes
- non-developers aren't spammed with e-mail they don't understand after reporting crashes
- the error message, explaining that a window just disappeared because the application crashed, appears in release versions of the software -- not just alphas and betas
- contributors can easily see which are the most common causes of crashes
- contributors can easily see how reliable their software is compared with previous versions.

For these reasons, Ubuntu should have an error tracker too.

Overview of crash reporters: http://en.wikipedia.org/wiki/Crash_reporter
Public statistics from Mozilla: https://crash-stats.mozilla.com/products/Firefox
Previous blueprint: https://launchpad.net/ubuntu/+spec/crash-reporting

Blueprint information

Status:
Complete
Approver:
Steve Langasek
Priority:
Medium
Drafter:
Evan
Direction:
Approved
Assignee:
Evan
Definition:
Superseded
Series goal:
Proposed for precise
Implementation:
Unknown
Milestone target:
milestone icon ubuntu-12.04
Completed by
Evan on 2011-11-18

Related branches

Sprints

Whiteboard

Work items:
[mpt] Design the user interface for the crash database: DONE
[ev] Work with Martin Pitt and Robert Collins to set the parameters of the crash database design: DONE
[ev] Implement a proof of concept automatic crash database, building on oops-repository, Socorro, or something else: TODO

pitti, 2011-05-19: Some comments about the goals:
- no sign-on account> What is the goal of this? More people reporting crashes? We don't currently lack crash reports, we lack people to work on the millions of existing ones. Also, this will make it a lot harder to work on them, as you have no way of getting back to the reporter and ask him for more information or testing packages
- e-mail notifications about dupes> That's a nuisance indeed. This is something that doesn't just apply to crash reports, but it should just be configurable in LP for all bugs.
- email spam for non-devs> see my first comment; right now we actually don't practically expect non-technical users to report crashes, but we do expect them to follow up to questions. If that DB just becomes a black hole for crash reports where nobody ever follows up to, what's the benefit for the user? For the vast majority of the reports they would have gone through the effort in vain, which might create even more frustration. Also, we don't want to enable crash reports in stable releases, and people running the development release are generally technically savvy enough to be able to handle a bug report.
- error message about crash> that's orthogonal to the issue. We could very well implement this client-side only dialog regardless of which crash DB we use.
- statistics: You can search for bugs with the apport-crash tag and sort by duplicates. But we don't automatically set an "affects me too" if you try to submit an already reported crash, so I agree that this is not too helpful right now (although even we do show potential dupes we still get a lot of actual dupes reported, so it does correlate well). From my POV this is the main shortcoming of our current system, so addressing this is most welcome.

ev, 2011-05-27: I believe Martin's concerns were addressed in a separate email thread, but Martin, if you feel these haven't been answered, do speak up :).

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.