AutomatedProblemReports
Differences between revisions 6 and 7
|
Size: 1134
Comment: pri
|
Size: 1471
Comment: added some agenda topics
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 28: | Line 28: |
| * 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 30: | Line 30: |
| * additional run-time information (environment, command line arguments, user comments for reproduction) | |
| Line 31: | Line 32: |
| * Handling and caching of debug symbols on client |
Priority
People
Goal
Streamline the process of collecting data for common end-user problems, so that they can be prioritized and addressed
Requirements
- 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]?
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
Pre-Work
MartinPitt already has a prototype for crash reports, see AutomatedCrashReporting
AutomatedProblemReports (last edited 2008-08-06 16:26:25 by localhost)