Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/xdeltas

• Created: Date(2006-06-20T16:09:54Z) by MattZimmerman

• Contributors: MattZimmerman

• Packages affected:

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

3 main use cases (added from BOF discussion --AndreasLloyd):

• 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.

Scope

We will implement two solutions:

1. Extend reportbug to use Malone's XMLRPC API for filing a bug
2. 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

Design

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.

Implementation

Code

Data preservation and migration

Results from last BoF

• Allowing anonymous bug reporting is too much work for the Launchpad developers, it won't get done in time.
• Instead the collected data to be associated with the bug will be uploaded anonymuosly to Launchpad, and the client will get a token back.

• 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>)

• 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.

• 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.

The changes required in Launchpad for this to work will be specced on the Launchpad wiki.

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.

CategorySpec