ApportForUpstreams
|
Size: 516
Comment: initial template
|
Size: 4628
Comment: correct status of bug-buddy patches
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| * '''Packages affected''': `apport` | * '''Packages affected''': `apport`, `bug-buddy` |
| Line 10: | Line 10: |
| Eventually we want to merge systems like bug-buddy and apport. We describe the steps and changes needed to make apport usable for upstreams (and other distributions). As a side effect this will allow us to automatically forward crash bugs to upstream. |
|
| Line 11: | Line 13: |
Some upstreams like Gnome currently maintain their own crash handling infrastructure. They are not directly applicable to Ubuntu because they are confined to particular applications, do not talk to Launchpad, do not collect packaging information, and are not easily extensible (like apport hooks). However, the general workflow is almost identical to ours, so it makes sense to promote apport as a general solution for upstreams, too. |
|
| Line 14: | Line 18: |
| * Olav is a Gnome upstream developer who works on Ubuntu. He has some Gnome upstream packages built from jh-build. The other day his panel crashes; the crash handler notices that the panel is not from an Ubuntu package, but an upstream version and reports the bug directly to upstream's bugzilla. * Sebastien uses the Ubuntu Gnome packages. Evolution crashes, and apport sends a bug report to Launchpad. The crash bug processor detects that this is not a duplicate of an already existing bug and automatically opens a bug in upstream's bugzilla with the collected information and retraced stack traces. |
|
| Line 15: | Line 23: |
These changes affect the crash interception and database parts of apport. It does not discuss changes to the packaging system interface (which also needs some refactorization to allow RPM-based distros to use apport). The generalization of apport is designed around the use case of Gnome upstream at the backend level for now. Further changes might be necessary in the future, especially merging of the client-side user interface and support for more types of bug trackers. |
|
| Line 18: | Line 30: |
| * '''Data format:''' The basis for collaboration is a shared and generic data format for crash reports. Once that is established, the entire process breaks into several smaller components (interception, data collection and user interaction, sending to crash database, stack trace recombination, duplicate detection, crash database updating) which are independent from each other and can be merged/unified at different times. * '''Crash interception:''' Bug buddy will be re-enabled by default. It tests whether a crash affects a native upstream executable and is built in an appropriate way. If so, it reports the crash directly to upstream, otherwise it re-raises the signal and let the distribution's apport handle it. * '''Crash database API''': Apport and some tools currently hardcode the Launchpad interaction. This will be refactored. Once this is done, then both distributions and upstreams can select the target crash database easily, which also allows us to seamlessly and automatically forward bugs to upstream bugzilla. |
|
| Line 20: | Line 38: |
| == Outstanding Issues == | * '''Data format:''' Proper documentation of apport's current RFC822 data format and defined fields and semantics will be created and sent to the Gnome maintainers for review. Bug buddy does not have a formal data format at the moment, and the Gnome crash handler/db maintainers (Fernando Herrera and Olav Vitters) generally agree to our's. This documentation should also describe the library that apport uses (`python-problem-report`) to read and write this format. * '''Crash interception:''' There already is some preliminary code for bug-buddy to check those conditions. The precise approach and implementation is left for the upstream maintainers. |
| Line 22: | Line 42: |
| == BoF agenda and discussion == | * '''Crash database API''': Similar to the packaging system API, an abstract `CrashDatabase` class API will be created. Ubuntu will provide an implementation of this for Launchpad. The Gnome maintainers will make the necessary changes to Bugzilla and provide a Bugzilla implementation of `CrashDatabase`. While we will continue to get crash bug duplicates at the distribution level, we can avoid forwarding duplicate bugs to upstream when we have duplicate detection on our end. Upstream will add a 'me too' counter to Bugzilla which we will trigger on incoming duplicate bugs (this provides a metric for prioritization). The API needs to support such a counter. |
Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: apport-for-upstreams
Packages affected: apport, bug-buddy
Summary
Eventually we want to merge systems like bug-buddy and apport. We describe the steps and changes needed to make apport usable for upstreams (and other distributions). As a side effect this will allow us to automatically forward crash bugs to upstream.
Rationale
Some upstreams like Gnome currently maintain their own crash handling infrastructure. They are not directly applicable to Ubuntu because they are confined to particular applications, do not talk to Launchpad, do not collect packaging information, and are not easily extensible (like apport hooks). However, the general workflow is almost identical to ours, so it makes sense to promote apport as a general solution for upstreams, too.
Use Cases
- Olav is a Gnome upstream developer who works on Ubuntu. He has some Gnome upstream packages built from jh-build. The other day his panel crashes; the crash handler notices that the panel is not from an Ubuntu package, but an upstream version and reports the bug directly to upstream's bugzilla.
- Sebastien uses the Ubuntu Gnome packages. Evolution crashes, and apport sends a bug report to Launchpad. The crash bug processor detects that this is not a duplicate of an already existing bug and automatically opens a bug in upstream's bugzilla with the collected information and retraced stack traces.
Scope
These changes affect the crash interception and database parts of apport. It does not discuss changes to the packaging system interface (which also needs some refactorization to allow RPM-based distros to use apport).
The generalization of apport is designed around the use case of Gnome upstream at the backend level for now. Further changes might be necessary in the future, especially merging of the client-side user interface and support for more types of bug trackers.
Design
Data format: The basis for collaboration is a shared and generic data format for crash reports. Once that is established, the entire process breaks into several smaller components (interception, data collection and user interaction, sending to crash database, stack trace recombination, duplicate detection, crash database updating) which are independent from each other and can be merged/unified at different times.
Crash interception: Bug buddy will be re-enabled by default. It tests whether a crash affects a native upstream executable and is built in an appropriate way. If so, it reports the crash directly to upstream, otherwise it re-raises the signal and let the distribution's apport handle it.
Crash database API: Apport and some tools currently hardcode the Launchpad interaction. This will be refactored. Once this is done, then both distributions and upstreams can select the target crash database easily, which also allows us to seamlessly and automatically forward bugs to upstream bugzilla.
Implementation
Data format: Proper documentation of apport's current RFC822 data format and defined fields and semantics will be created and sent to the Gnome maintainers for review. Bug buddy does not have a formal data format at the moment, and the Gnome crash handler/db maintainers (Fernando Herrera and Olav Vitters) generally agree to our's. This documentation should also describe the library that apport uses (python-problem-report) to read and write this format.
Crash interception: There already is some preliminary code for bug-buddy to check those conditions. The precise approach and implementation is left for the upstream maintainers.
Crash database API: Similar to the packaging system API, an abstract CrashDatabase class API will be created. Ubuntu will provide an implementation of this for Launchpad. The Gnome maintainers will make the necessary changes to Bugzilla and provide a Bugzilla implementation of CrashDatabase. While we will continue to get crash bug duplicates at the distribution level, we can avoid forwarding duplicate bugs to upstream when we have duplicate detection on our end. Upstream will add a 'me too' counter to Bugzilla which we will trigger on incoming duplicate bugs (this provides a metric for prioritization). The API needs to support such a counter.
ApportForUpstreams (last edited 2008-08-06 16:39:59 by localhost)