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
Test Plan
User Experience
[1] shows this feature in action.
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.