Features/SaveToBugzilla

Save exception reports straight to bugzilla

Summary

anaconda's had the ability to save exception reports to another machine via scp for a while now. However this only really helps you if you have another machine nearby that you have an account on. This presents a pretty significant barrier to getting exception reports. In addition, people don't usually include all the information we need in a bug report so we have to go back and forth asking for them to attach files.

Instead, it would be much easier if we supported the ability to save tracebacks to bugzilla.

Owner

• Name: ChrisLumens (clumens@redhat.com)

Current status

• Targeted release: Fedora 10
• Last updated: 2008-07-22
• Percentage of completion: 80% - some final testing and polish still needs to be added

Detailed Description

In addition to the existing scp exception saving report, this feature adds support to save straight to bugzilla.redhat.com (or elsewhere - see later for more description of this). It adds a third option to the "Save Exception" dialog in anaconda. The user will be required to have a preexisting bugzilla account - there's no provision to add a new user and then file the bug. This is partially due to python-bugzilla not having support for that feature, and partially as a way to keep bug spam down.

The user is prompted for their account name and password, and a summary for the new bug. We then file the bug and add as an attachment the traceback file. One problem here is the possibility for lots of duplicate bugs being filed, since it's now so easy to file one. To prevent this, we have duplicate bug detection. Part of the traceback is hashed. On new bug reports, the hash is stored in the status_whiteboard. Then before filing a new bug, we query bugzilla to see if there are any preexisting reports with that same hash, indicating the same bug. If so, the user is added to the CC list and their exception report is attached to the bug in case there is slightly new information causing the same traceback.

Either way, the user is notified of what happened and directed to the bug URL for their bug. They then have the only option of quitting anaconda.

Not all distributions that use anaconda use Red Hat's bugzilla, and some don't use any bugzilla instance at all. To handle this, we have an abstraction layer that allows distributors to specify their own bug handling system through anaconda's InstallClasses. A distributor could reference the appropriate bug handling class in their custom InstallClass, put that into a product.img, and anaconda would handle it correctly. This has yet to be tested. For distributions that do use bugzilla, they would just need to instantiate the existing bug handling code with the proper URL.

Benefit to Fedora

We lower the barrier to getting bugs filed about anaconda. Because of the strange environment we are running in, it can be difficult to get debugging information (the user's only computer could be in the middle of an install when an error is hit, for instance). This makes it easier for them to report problems to us provided they have a network connection. The duplicate checking should cut down on the number of bugs we receive that all report the same thing.

Scope

• FIXME

Test Plan

• FIXME

User Experience

• [1] shows this feature in action
• Additional drop-down in to submit traceback to redhat.bugzilla.com

Dependencies

Requires adding python-bugzilla to the stage2 image. This is already in Fedora and is pretty small so there shouldn't be any problems here.

Contingency Plan

No contingency plan necessary since most of this has already been committed.

Documentation

• FIXME

Release Notes

• FIXME