Bugs/Specs/CrashDatabase

Not logged in - Log In / Register

This specification is a historical document about a feature that was not not implemented.

Summary

This document is an overview of what the Crash Database will look like. The actual implementation will be done in at least 3 phases:

These phases will be described in their own specs. This document is for discussion and does not describe implementation.

This is based on the IRC discussion between BjornTillenius, ChristianReis and MartinPitt. IRC-log

Rationale

apport files crash reports as public bugs in Malone. This has privacy issues because crash reports can contain sensitive information. See UbuntuWiki:CrashReporting for an earlier discussion.

During the reporting process, users are asked if their crash is a duplicate of an existing problem. Perhaps due to uncertainty, many users file their crash again and so there are many duplicates. Sorting this out is a burden on the bug squad, and is the main reason apport is currently disabled in Feisty.

Use cases

Filing

Dealing with reports

Design

Each crash report will be a collection of all the uploaded information about a crash, along with:

Privacy

Not everyone should see crash reports to begin with. This will probably be done by adding a new role to products and distros.

However, when crash reports are promoted to bugs (see later on), the bug assignee will need to be able to see the reports. XXX Is this going to be done by making crash reports public? Do we need to care at first, because the whole Ubuntu QA Team will probably be able to see all crash reports?

XXX What will the work flow look like? Will every crash report be reviewed for sensitive data, or just the report used to create a bug? Need to discuss this!

Email notifications

There will be no email notifications at first because of the anticipated volume of crash reports from Ubuntu and Launchpad. Later on it may be good to send notifications for smaller projects.

Grouping crash reports

We expect to get multiple reports of a similar issue. The responsibility for deduplicating issues has been taken away from the user (because it wasn't working very well), and we must have a mechanism for managing it ourselves. The options:

The chosen solution has to work both for Ubuntu (lots of crashes, want retracer to do everything automatically) and for smaller projects like Launchpad (fewer crashes, triage via web UI).

Creating bugs from crash reports

A bug can be created from a single crash report in the web UI. The title and description fields will be prefilled but left editable, and the option will be given to subscribe the crash reporter to the bug. Because crash reports will often be grouped (by similar, fingerprint or otherwise), the option should be given to subscribe the reporters of all the related crashes. Those subscribed will be sent a specific email stating that their crash has been promoted into a bug.

The bug reporter will be the person who promotes the crash report into the bug, not the original crash reporter.

XXX Many crash reporters will be happy to be contacted for more information but will not want or understand all the normal Malone status emails. However, there is currently no way to model this, except if we accept anonymous crash reports.

Bug pages

A bug page will need to show referenced crash reports.

Ubuntu retracer

XXX Need to talk to MartinPitt about how the retracer will interface with Launchpad.

Discussion

Notes from the London meeting 2007-06:

8. crash-database
    - crash database is something that would be good to make available to
        launchpad onsite customers. configure apport to report certain crashes
        to local onsite launchpad rather than public one.
    - does this mean that we need to allow crash reports to be
        forwarded on to launchpad.net by lp.onsite users?
    - It be good to standardise on the crash report format, so that we can
      send it to other crash databases. Pitti has already started talking
      to Gnome about this.
    - dogfooding as a backend for our OOPS reports
    - garbage collecting crashes is relevant since there is a good chance that.
      we end up with a /lot/ of old crashes.
    - crash db needs a way to allow people to mark crashes as related
    - we also need a way to automatically mark crashes as related. this
      will be different for each project, so we may need to use an
      external agent (per project) for this.
    - how important is having a proper crash database compared to
      everything else that needs to be done? what we have now already
      works reasonably well for Ubuntu.


CategoryProposal

Bugs/Specs/CrashDatabase (last edited 2011-07-02 21:54:47 by sinzui)