From Fedora Project Wiki
(Created page with "<!-- All fields on this form are required to be accepted by FESCo. We also request that you maintain the same order of sections so that all of the feature pages are uniform. --...")
 
No edit summary
Line 7: Line 7:


== Summary ==
== Summary ==
There are few problem reporting application (mechanisms)
Unify the UI for all problem reporting programs (mechanisms) in Fedora to improve the user experience by confronting them only one UI when reporting a problem.


== Owner ==
== Owner ==
Line 25: Line 25:
== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
The new reporting library will provide the same API as did the old backend (concerns only python programs - Anaconda, setroubleshoot, python-meh) so the change should be transparent without any change in the code. The only change (not required to make it work) would be to change the spec file to require the new library instead of the old one.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 30: Line 31:


== Scope ==
== Scope ==
The new reporting library will provide the same API as did the old backend (concerns only python programs - Anaconda, setroubleshoot, python-meh) so the change should be transparent without any change in the code. The only change (not required to make it work) would be to change the spec file to require the new library instead of the old one.
* create a bug reporting framework extensible by plugins by splitting the ABRT code - '''DONE'''
* create a libreport package and add it to Fedora - '''DONE'''
* create a python bindings for libreport - '''DONE'''
* package the python bindings in Fedora  - '''IN PROGRESS'''


== How To Test ==
== How To Test ==
TBD
- before the feature is accepted the unofficial packages can be found in this [http://repos.fedorapeople.org/repos/jmoskovc/abrt/fedora-abrt.repo repo]
=== 1. Install the following packages ===
* libreport
* libreport-gtk
* libreport-python (this one should obsolete the old report package)
* libreport-plugin-bugzilla (reporter plugin to create tickets in Fedora bugzilla)
=== 2. Try to report a problem ===
* Anaconda crash
* SELinux AVC
* crash detected by ABRT


Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
=== 3. Expected results ===
 
* if the bug is new then a new ticket should be created in bz
A good "how to test" should answer these four questions:
* if the bug was reported it should let user know it found a duplice
 
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this feature? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the feature is
working like it's supposed to?
3. What are the expected results of those actions?
-->


== User Experience ==
== User Experience ==
Line 60: Line 66:


== Contingency Plan ==
== Contingency Plan ==
"None necessary, revert to previous release behaviour."
None necessary, revert to previous release behaviour.


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
*
* Documents describing detailed configuration can be found [https://fedorahosted.org/abrt/wiki/AbrtDeployment2 here]
 
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
*


== Comments and Discussion ==
== Comments and Discussion ==
Line 76: Line 77:




[[Category:FeaturePageIncomplete]]
[[Category:FeatureReadyForWrangler]]
<!-- When your feature page is completed and ready for review -->
<!-- When your feature page is completed and ready for review -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Revision as of 09:19, 12 July 2011


Features/Unified_Problem_Reporting_UI

Summary

Unify the UI for all problem reporting programs (mechanisms) in Fedora to improve the user experience by confronting them only one UI when reporting a problem.

Owner

  • Email: jmoskovc@redhat.com

Current status

  • Targeted release: Fedora 16
  • Last updated: 2011-07-11
  • Percentage of completion: 20%


Detailed Description

The new reporting library will provide the same API as did the old backend (concerns only python programs - Anaconda, setroubleshoot, python-meh) so the change should be transparent without any change in the code. The only change (not required to make it work) would be to change the spec file to require the new library instead of the old one.

Benefit to Fedora

Unified user interface makes it easier for users to use it. Unifying the reporting backend will also mean that the config data is shared and users have to setup their credentials (like bugzilla name/password) only once.

Scope

  • create a bug reporting framework extensible by plugins by splitting the ABRT code - DONE
  • create a libreport package and add it to Fedora - DONE
  • create a python bindings for libreport - DONE
  • package the python bindings in Fedora - IN PROGRESS

How To Test

- before the feature is accepted the unofficial packages can be found in this repo

1. Install the following packages

  • libreport
  • libreport-gtk
  • libreport-python (this one should obsolete the old report package)
  • libreport-plugin-bugzilla (reporter plugin to create tickets in Fedora bugzilla)

2. Try to report a problem

  • Anaconda crash
  • SELinux AVC
  • crash detected by ABRT

3. Expected results

  • if the bug is new then a new ticket should be created in bz
  • if the bug was reported it should let user know it found a duplice

User Experience

The bug reporting UI will change for:

  • Anaconda uncaught exceptions
  • setroubleshoot reports
  • firstboot uncaught exceptions

Dependencies

  • Anaconda
  • python-meh
  • firstboot
  • setroubleshoot

Contingency Plan

None necessary, revert to previous release behaviour.

Documentation

  • Documents describing detailed configuration can be found here

Comments and Discussion

Retrieved from "https://fedoraproject.org/w/index.php?title=Features/Unified_Problem_Reporting_UI&oldid=245351"