BugReportingTool

Revision 2 as of 2006-06-20 16:19:41

Clear message

Summary

Rationale

Use cases

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

  • Reporting a bug from the system menu "system -> help -> report a bug"

  • Reporting a bug from the application "Help menu"

Something's wrong with an application, and Jeff clicks on the "report a bug" option from the app's Help menu. He immediately gets a list of bugs for that app (in the Launchpad web interface through the browser) and can easily recognize if that bug is already reported. Otherwise he can easily use Malone to file the bug like he would otherwise.

  • Automatically reporting a bug following an application crash.

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.

Scope

Design

Implementation

Code

Data preservation and migration

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