Ubuntu Wiki

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.

CategorySpec