AutomatedProblemReports

Differences between revisions 12 and 13
Revision 12 as of 2005-04-24 09:27:23
Size: 2256
Editor: intern146
Comment: people
Revision 13 as of 2005-04-26 12:18:46
Size: 2255
Editor: intern146
Comment: people
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
  * People: MichaelVogtLead, LamontJonesSecond[[BR]]   * People: MartinPittLead, MichaelVogtSecond[[BR]]

Status

Introduction

Streamline the process of collecting data for common end-user problems, so that they can be prioritized and addressed

Rationale

Scope and Use Cases

  • When a program crashes, send a report (with an absolute minimum of user interaction)
  • Extract and store debug symbols from standard builds, and store them in a centralized repository for use in analyzing these reports
  • When a package installation, removal or upgrade fails, send a report (with an absolute minimum of user interaction)
  • When a kernel panic/oops/etc. occurs, send a report (with an absolute minimum of user interaction)
  • [http://www.cs.wisc.edu/cbi/ Cooperative bug isolation]?

Implementation Plan

Data Preservation and Migration

Packages Affected

User Interface Requirements

Outstanding Issues

UDU BOF Agenda

  • What data needs to be submitted?
    • core dump; MartinPitt: core dumps are difficult to handle since you need to have exactly the same libraries; a good stack trace is already very helpful, much smaller, and easier to handle

    • identifying information for all code involved (package versions? filenames? md5sums?)
    • additional run-time information (environment, command line arguments, user comments for reproduction)
  • How should the debug symbol extraction work?
  • Handling and caching of debug symbols on client
  • Automated bug reporting to Malone

UDU Pre-Work

AutomatedProblemReports (last edited 2008-08-06 16:26:25 by localhost)