BugReportingTool

Differences between revisions 4 and 20 (spanning 16 versions)
⇤ ← Revision 4 as of 2006-06-22 12:55:53 →
Size: 4852
Editor: ALagny-109-1-9-136
Comment: start
← Revision 20 as of 2008-08-06 16:21:00 → ⇥
Size: 6815
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/xdeltas
 * '''Created''': [[Date(2006-06-20T16:09:54Z)]] by MattZimmerman
 * '''Contributors''': MattZimmerman
 * '''Packages affected''': 		 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/bug-reporting-tool
 * '''Packages affected''': apport, launchpad-integration
Line 18: Line 16:
3 main use cases (added from BOF discussion --AndreasLloyd):  * Bjorn notices that Evolution is misbehaving, so he selects the "Help -> Report a bug" menu entry in that application.
Line 20: Line 18:
 * Brad notices a bug in his desktop, but it isn't obviously the fault of any particular application. He uses the menu entry "system -> help -> report a bug" to file it.

 * Bjorn notices that Evolution is misbehaving, so he clicks on the "report a bug" option from the app's Help menu.

 * Celso is playing AisleRiot. He is about to win the game when it crashes. Helpfully, a dialog box pops up inviting him to report the crash. After throwing a chair across the room, he calms down and writes a useful bug report which eventually results in a fix.

 * Adam administers a Gopher server, and wishes to report a bug from that system, so that relevant information can be automatically included in the report. He uses a command-line tool to submit a complete bug report to Launchpad.		  * Brad notices a bug in his desktop, but it isn't obviously the fault of any particular application. He selects the "System -> Help -> Report a bug" menu entry.
Line 30: Line 22:
We will implement two solutions:

 1. Extend reportbug to use Malone's XMLRPC API for filing a bug
 1. Create a gateway to Malone's web UI which will allow the user to file their bug there, while automatically including relevant information from the system		 This specification describes a GUI client which requires a running X session. It is also desirable to develop a command line tool for reporting bugs on servers or reporting bugs when X is broken, but this should become a separate specification.
Line 37: Line 26:
In each use case a single "pop-up" will appear and allow the user to acknowledge the gathering of bug-relevant data, and then launch a browser with Launchpad, and put the data in a "cloakroom" and open launchpad with a set ticket connected to that data which will be attached to that bug report. === Overview ===

In order to not duplicate functionality, we use the existing Malone web UI instead of creating two more desktop UIs (for Gnome and KDE). The local agent will collect debugging information, direct the user to the Malone bug page, and makes sure that the debugging information is sent to Malone and gets attached to the new bug report.

The workflow and data collection is very similar to the current apport crash detection system, so we will extend the apport libraries and frontend to support general bug reporting, and then treat crash reports as a special case of bug report.

=== Frontend workflow ===

 0. If the frontend is invoked from a running application, it already knows which package contains the bug. If it is called from "System -> Help -> Report a bug", it should ask for the source package name, or "I don't know" (in which case we are going to report a generic distribution bug).
 0. Display an indefinite progress bar dialog asking the user to wait while debug data is collected.
 0. Submit the debug information to Malone's temporary holding area ("cloakroom") and record the handle for it.
 0. Open the `+filebug` page with `extra_info=<token>` URL argument and close the local frontend. The `+filebug` page is opened in a new Firefox (Ubuntu/Xubuntu) or Konqueror (Kubuntu) window. Launchpad will then guide the user through the bug filing process (including the suggestion to check whether the bug was already reported). (Note: HTTP POST is not possible with externally calling firefox with an URL.)

=== Data submission ===

The Launchpad cloakroom will accept a MIME multipart message. Message parts with Content-Disposition: inline will be included as comments, while those with Content-Disposition: attachment will become attachments. The first inline message part will be appended to the user's summary of the bug, while subsequent inline message parts will be included as additional comments.
Line 41: Line 45:
=== Collected debug data ===

apport collects various useful debug data and assembles a MIME/multipart document (instead of the currently-used debcontrol format). Large file attachments like core dumps will use gzip content encoding for compression.

The following information will be always collected:

 * `lsb_release -sir` output (inline)
 * `uname -a` output (inline)
 * `groups` output, with all groups >= 1000 removed for privacy reasons (inline)

If the bug is filed against a particular package (when specifying a package when using System -> Help -> Report a bug), this additional information will be collected:

 * package name and version (inline)
 * source package name (inline)
 * Dependencies: package names and versions of all dependencies and pre-dependencies (attachment)

If we have an associated process (if we get called from launchpad integration's menu), we additionally collect:

 * Executable``Path: /proc/pid/exe contents; if the crashed process is interpreted, this contains the script path instead (inline)
 * Interpreter``Path: /proc/pid/exe contents if the crashed process is interpreted; otherwise this key does not exist (inline)
 * Proc``Environ: A non-sensitive subset of the process' environment (SHELL, PATH, LD_PRELOAD (if nonempty), LD_LIBRARY_PATH (if nonempty), locale information) (attachment)
 * Proc``Cmdline: /proc/pid/cmdline contents (inline)

If the bug report is a crash, additionally collect the following:

 * Proc``Status: /proc/pid/status contents (attachment)
 * Proc``Maps: /proc/pid/maps contents (attachment)
 * Core``Dump: gzip compressed core dump (attachment)
 * Stack``Trace: Output of gdb's 'bt full' command (attachment)
 * Thread``Stacktrace: Output of gdb's 'thread apply all bt full' command (attachment)
 * Top 5 lines of `bt` (inline)
Line 42: Line 78:

The proposed workflow is similar to the current crash reporting in apport. The following changes are necessary to apport:

 * Accept a `--file-bug` mode to `apport-gtk` with an optional package name. (Right now `apport-gtk` does not accept any parameters and just displays pending crash reports).
 * Add a dialog for entering the package name (or choosing "I don't know") to `apport-gtk`, which will be shown if no package was supplied as command line argument.
 * Implement cloakroom submission and missing data collection in `apport_utils`.
Line 45: Line 87:
== Results from last BoF == No data migration needs to happen.
Line 47: Line 89:
  * Allowing anonymous bug reporting is too much work for the Launchpad developers, it won't get done in time. If disk space in Launchpad becomes an issue, it is possible to remove large bug attachments like core dumps from closed and duplicate bug reports. Data in bug comments should be preserved forever.
Line 49: Line 91:
  * Instead the collected data to be associated with the bug will be uploaded anonymuosly to Launchpad, and the client will get a token back. == Testing ==
Line 51: Line 93:
  * The user will be sent to the relevant source packagage's +filebug page, with the token of the uploaded data given as a query parameter. (Something like `https:/.../+filebug?extra_info=<token>`) Using the GUI:
Line 53: Line 95:
  * If the user has a Launchpad account he'll be prompted to log in, and after he's logged in he'll return to the `+filebug?extra_info=<token>` page where he can file the bug with the collected data attached to the bug.  * Open `gedit`. It's help menu should have a ''Report a bug'' entry. Clicking that should bring up two progress dialogs ("collecting info" and "uploading report") and open your default browser with an URL like `https://launchpad.net/ubuntu/+source/gedit/+filebug/hWh3sQqXxg6NuqYNxrPZpQXFnDw`, i. e. the gedit "file bug" Malone page with a ticket number appended.
 * ''System'' -> ''Report a problem'' should file a generic distro bug, i. e. open an URL like `https://launchpad.net/ubuntu/+filebug/hAib3Rn1BiCXff2547liNDckYX2`.
Line 55: Line 98:
  * If the user doesn't have a Launchpad account he'll be prompted to create one, and after the registration process is finished, he should be returned to the `+filebug?extra_info=<token>` page where he can file the bug with the collected data attached to the bug. Using the `ubuntu-bug` script:
Line 57: Line 100:
The changes required in Launchpad for this to work will be specced on the Launchpad wiki.  * Running `ubuntu-bug -p bash' files a bug against bash. Similarly to the gedit case, it collects info and opens https://launchpad.net/ubuntu/+source/bash/+filebug/qWj8ycQP8ZrgbeSDt8Fc6QHmnx9.
 * Running `ubuntu-bug` files a distro bug, just like the ''System'' -> ''Report a problem'' case above.
Line 59: Line 103:
== Old disussion ==
=== Outstanding issues ===

 * Determine whether to write a client-side UI or hand off as much as possible to Malone via browser
 * Specify client-side UI (must at least ask before submitting information)

=== BoF agenda and discussion ===
Options:
 * reportbug: too clumsy
 * bug-buddy: author would be happy to see a python rewrite
 * integration of package-specific data collection
 * look for similar bugs in Launchpad and have user check for dups
 * XMLRPC interface will change much less than the web UI
 * direct the user to the web UI will avoid having to maintain two separate big (KDE/Gnome) user interfaces which will not change any more in stable releases
 * three ways of entering a bug:
  * from Help menu of app
  * from System menu (do not ask for which package)
  * automatically popped up crash
  
Future:
 * improve the UI to ask for package/bug category; this requires a minimal UI that could be integrated into launchpad-integration

Pros:

 * Easier to extend
 * Web bug reporting UI can change alongside Malone after release.
 * Client is easier to implement
 * One single UI to keep up-to-date, don't have to revise n-different clients

Con:
 * Server is more difficult to implement (cloakroom)
 * Can't report certain types of browser crashes. But you can't report
   certain types of bug-reporting-tool crashes anyway.
 * Pushed all the development on to poor, tired, overworked Malone developers. Which
   we love.

Summary

We will develop client-side applications which assist the user in reporting a bug to Malone.

Rationale

A client-side application allows us to automatically collect information from the system which will be helpful in analyzing the bug report. This will save oodles of time for developers and those involved in bug triage, resulting in more bugs being triaged, more bugs being closed, and a higher quality Ubuntu.

Use cases

  • Bjorn notices that Evolution is misbehaving, so he selects the "Help -> Report a bug" menu entry in that application.

  • Brad notices a bug in his desktop, but it isn't obviously the fault of any particular application. He selects the "System -> Help -> Report a bug" menu entry.

Scope

This specification describes a GUI client which requires a running X session. It is also desirable to develop a command line tool for reporting bugs on servers or reporting bugs when X is broken, but this should become a separate specification.

Design

Overview

In order to not duplicate functionality, we use the existing Malone web UI instead of creating two more desktop UIs (for Gnome and KDE). The local agent will collect debugging information, direct the user to the Malone bug page, and makes sure that the debugging information is sent to Malone and gets attached to the new bug report.

The workflow and data collection is very similar to the current apport crash detection system, so we will extend the apport libraries and frontend to support general bug reporting, and then treat crash reports as a special case of bug report.

Frontend workflow

  1. If the frontend is invoked from a running application, it already knows which package contains the bug. If it is called from "System -> Help -> Report a bug", it should ask for the source package name, or "I don't know" (in which case we are going to report a generic distribution bug).

  2. Display an indefinite progress bar dialog asking the user to wait while debug data is collected.
  3. Submit the debug information to Malone's temporary holding area ("cloakroom") and record the handle for it.

  4. Open the +filebug page with extra_info=<token> URL argument and close the local frontend. The +filebug page is opened in a new Firefox (Ubuntu/Xubuntu) or Konqueror (Kubuntu) window. Launchpad will then guide the user through the bug filing process (including the suggestion to check whether the bug was already reported). (Note: HTTP POST is not possible with externally calling firefox with an URL.)

Data submission

The Launchpad cloakroom will accept a MIME multipart message. Message parts with Content-Disposition: inline will be included as comments, while those with Content-Disposition: attachment will become attachments. The first inline message part will be appended to the user's summary of the bug, while subsequent inline message parts will be included as additional comments.

Implementation

Collected debug data

apport collects various useful debug data and assembles a MIME/multipart document (instead of the currently-used debcontrol format). Large file attachments like core dumps will use gzip content encoding for compression.

The following information will be always collected:

  • lsb_release -sir output (inline)

  • uname -a output (inline)

  • groups output, with all groups >= 1000 removed for privacy reasons (inline)

If the bug is filed against a particular package (when specifying a package when using System -> Help -> Report a bug), this additional information will be collected:

  • package name and version (inline)
  • source package name (inline)
  • Dependencies: package names and versions of all dependencies and pre-dependencies (attachment)

If we have an associated process (if we get called from launchpad integration's menu), we additionally collect:

  • ExecutablePath: /proc/pid/exe contents; if the crashed process is interpreted, this contains the script path instead (inline)

  • InterpreterPath: /proc/pid/exe contents if the crashed process is interpreted; otherwise this key does not exist (inline)

  • ProcEnviron: A non-sensitive subset of the process' environment (SHELL, PATH, LD_PRELOAD (if nonempty), LD_LIBRARY_PATH (if nonempty), locale information) (attachment)

  • ProcCmdline: /proc/pid/cmdline contents (inline)

If the bug report is a crash, additionally collect the following:

  • ProcStatus: /proc/pid/status contents (attachment)

  • ProcMaps: /proc/pid/maps contents (attachment)

  • CoreDump: gzip compressed core dump (attachment)

  • StackTrace: Output of gdb's 'bt full' command (attachment)

  • ThreadStacktrace: Output of gdb's 'thread apply all bt full' command (attachment)

  • Top 5 lines of bt (inline)

Code

The proposed workflow is similar to the current crash reporting in apport. The following changes are necessary to apport:

  • Accept a --file-bug mode to apport-gtk with an optional package name. (Right now apport-gtk does not accept any parameters and just displays pending crash reports).

  • Add a dialog for entering the package name (or choosing "I don't know") to apport-gtk, which will be shown if no package was supplied as command line argument.

  • Implement cloakroom submission and missing data collection in apport_utils.

Data preservation and migration

No data migration needs to happen.

If disk space in Launchpad becomes an issue, it is possible to remove large bug attachments like core dumps from closed and duplicate bug reports. Data in bug comments should be preserved forever.

Testing

Using the GUI:

  • Open gedit. It's help menu should have a Report a bug entry. Clicking that should bring up two progress dialogs ("collecting info" and "uploading report") and open your default browser with an URL like https://launchpad.net/ubuntu/+source/gedit/+filebug/hWh3sQqXxg6NuqYNxrPZpQXFnDw, i. e. the gedit "file bug" Malone page with a ticket number appended.

  • System -> Report a problem should file a generic distro bug, i. e. open an URL like https://launchpad.net/ubuntu/+filebug/hAib3Rn1BiCXff2547liNDckYX2.

Using the ubuntu-bug script:

CategorySpec

BugReportingTool (last edited 2008-08-06 16:21:00 by localhost)