||This specification is a historical document about a feature that was not not implemented.|| * '''Launchpad entry:''' https://blueprints.launchpad.net/launchpad/+spec/crash-database * '''Created:''' <> by GavinPanella * '''Contributors:''' BjornTillenius, ChristianReis, MartinPitt == 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: * Get `apport` in Ubuntu to file crash reports instead of bugs. * Move the Launchpad OOPS system to the crash database. * Allow anonymous crash reporting. 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. [[attachment:IRC-log]] == Rationale == `apport` files crash reports as public bugs in Malone. This has privacy issues because crash reports can contain sensitive information. See [[https://wiki.ubuntu.com/CrashReporting|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 === * Millie was logging in to her bank account when Firefox crashed. She's used to clicking the "Send" button for Windows Error Reporting, so she does the same for apport. Her banking password can be found in the crash information, so this needs to be treated confidentially. * Joe Normal has a crash in Inkscape. `apport` asks him to submit a report, and takes him to the Launchpad Crash Report page. He's asked to tell us what he was doing at the time of the crash and anything else he thinks might be important, then he submits the report. * '''Advanced''': Mike Developer has a crash in Pidgin. He can see right away that this is a new bug. He's already a Bug Contact for Pidgin, so the Launchpad Crash Report page gives him the option to directly file a bug, which he does. * Anon had a crash in `pornview`. He's cagey about logging into Launchpad to report this crash because he was at work at the time, but it's a valid report. Launchpad files an anonymous crash report. === Dealing with reports === * A new crash report arrives for a Ubuntu application. The retracer service obtains the crash files it needs from the Librarian, processes them and adds the results to the crash report. XXX Ask MartinPitt what should happen next. * Joanne gets an OOPS on Launchpad. The OOPS is saved to the crash database. XXX How will this work for OOPS reports? * Simon Privileged looks at a submitted crash report and sees that there is no private data within. He marks it as non-sensitive. == Design == Each crash report will be a collection of all the uploaded information about a crash, along with: * Title. Automatically created by `apport` and probably not end-user editable. * Description. Automatically created by `apport` and probably not end-user editable. * Who reported the crash. * What the user was doing at the time (symptoms). * Anything else the user feels might be helpful in understanding the crash. * Whiteboard. * The target, either a product or a source package. * A reference to a derived bug, if it exists. === 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: * Use a ''similar'' field, populated by an external process. * Use bugs to group. If two crash reports are similar, link them both to the same bug. * ''Fingerprint'' field, i.e. a carefully derived check-sum. Used to find similar crash reports. An enhanced `retracer` service will probably need something like this. * Create a new crash report ''collection''. 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. * Via a portlet or directly in the bug page. Show the top/first 5 crash reports, direct links to their attachments (or the most pertinent ones), and a link to see all crash reports. * A summary of crash reports in the page or portlet, with totals, etc., and a link to see the details. * A list of crash report IDs, which expand or pop-up when clicked. === 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