AutomatedProblemReports

Differences between revisions 2 and 8 (spanning 6 versions)
⇤ ← Revision 2 as of 2005-04-10 23:39:26 →
Size: 988
Editor: ca-studio-bsr1o-251
Comment: merge zwiki stuff
← Revision 8 as of 2005-04-23 05:46:42 → ⇥
Size: 2177
Editor: ppp112-230
Comment: convert to SpecTemplate
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= People = = Priority =
##(see the SpecSpec for an explanation)
Line 3: Line 4:
 * MartinPitt
 * LaMontJones
 * MichaelVogt		 = UbuntuDownUnder/BOFs/UbuntuDevelopment/AutomatedProblemReports =
Line 7: Line 6:
= Goal = == Status ==

  * Created: [[Date(2005-04-23T05:46:42Z)]] by MattZimmerman[[BR]]
  * Priority: LowPriority[[BR]]
  * People: NeedsLead, NeedsSecond[[BR]]
  * Contributors: MattZimmerman[[BR]]
  * Interested: MartinPitt, LaMontJones, MichaelVogt, SebastienBacher[[BR]]
  * Status: BrainDump, BreezyGoal, UduBof, DistroSpecification[[BR]]
  * Branch: [[BR]]
  * Malone Bug: [[BR]]
  * Packages: [[BR]]
  * Depends: [[BR]]
  * UduSessions: 1, 4, 8, etc [[BR]]

== Introduction ==
Line 12: Line 26:
= Requirements = == Rationale ==

== Scope and Use Cases ==
Line 20: Line 36:
= Agenda = == Implementation Plan ==

=== Data Preservation and Migration ===

=== Packages Affected ===

=== User Interface Requirements ===

== Outstanding Issues ==

=== UDU BOF Agenda ===
Line 23: Line 49:
  * core dump   * 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
Line 25: Line 51:
  * additional run-time information (environment, command line arguments, user comments for reproduction)
Line 26: Line 53:
 * Handling and caching of debug symbols on client
Line 28: Line 56:
= Pre-Work = === UDU Pre-Work ===

 * MartinPitt already has a prototype for crash reports, see AutomatedCrashReporting

Priority

UbuntuDownUnder/BOFs/UbuntuDevelopment/AutomatedProblemReports

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)