Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 736728 - abrt's timing for commenting is just plain stupid!
Summary: abrt's timing for commenting is just plain stupid!
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jiri Moskovcak
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-08 14:22 UTC by Peter Hjalmarsson
Modified: 2015-02-01 22:54 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-08-30 00:58:01 UTC
Type: ---

Attachments (Terms of Use)

Description Peter Hjalmarsson 2011-09-08 14:22:47 UTC
Description of problem:
Every new version of abrt seems to bring its own stupidness, and hinderences to report a bug in a sane way, and with Fedora 16 it even got worse!
Nowdays you ALWAYS have to type something into the comment field BEFORE you know anything about the bug or even do NOT HAVE TO!

In this case see the following scenario:
My kernel gives a BUG_ON/WARNING_ON. ABRT picks it up. I want to report it to kerneloops.org.
Now to send it in I have to:
1. Write a comment
2. choose if I want to generate/update a smolt profile
3. choose to report to kerneloops.org
4. choose what to report to kerneloops.org.

Now here comes the questions: how much of these things do kerneloops.org even accept? Last time I checked only the stacktrace. So why do I have to enter a comment and choose to not generate a smolt profile?

It gets even more funny if I crash empathy.
Now I have been hit by a long standing crash with empathy time and time over, which is already reported. You can recognize it in the backtrace.
So nowdays to analyze if this is the same bug I hit again (and maybe able to write a comment in the right bug, or a more informative comment in a new bug) I have to jump the following hoops:
1. Write a arbitrary comment
2. choose to generate a backtrace
3. choose to not generate a smolt profile
4. choose to report the bug (to logger or bugzilla)
5. analyze the backtrace
6. back out to step 1 and repeat but with more informed information.

So how could this be done better?

1. Do things in the right order and have them depend on each other!

1.1 Start with what reporting plugin!

1.2 Then backtrace ASAP!!!
 - This will make sure that people who actually can analyze it do not have to jump too many hoops to be able to do it
 - If you think it that it is more userfriendly to start with the comment you are wrong. As a new user to have to come up with a comment and then be presented with a backtrace wall of text is a no-go. It would be better to have a button called "Help!" with a textbox saying "just look so that it does not contain any passwords , names or other personal information".

1.3 Present the user with dialogs based on the choose reporting plugin (i.e. NO COMMENT-step if the target does not support comments, NO smolt if the target does not support )

2. Do as much as possible in one go!
 - for example, with smolt, why do we have to stop the guide to generate the profile? I think it would be better to have everything that generates output the user do not approve in one go, last with the actual send. the user should have to wait as little as possible to provide new data.

So with other words, the flow should go:

1. Choose plugin so abrt know what it needs to generate.
2. generate all output the report plugin wants and that the user need to approve. If possible give the user the choice to background it.
3. collect all the information needed from the user the plugin wants and the user needs to enter and approve, in order of what may create the best user-written comments from an informed user, and with a layout less confusing for a novice.
4. generate and send anything else. With the possibility to background it.

Comment 1 Fedora Update System 2012-08-10 10:43:58 UTC
libreport-2.0.12-2.fc17, abrt-2.0.11-1.fc17, btparser-0.18-2.fc17 has been submitted as an update for Fedora 17.

Comment 2 Jiri Moskovcak 2012-08-10 10:46:58 UTC
The latest version tries to do exactly what's described in comment#1 - it tries to do as much as it can in one step, asking the user input at one place.

Comment 3 Fedora Update System 2012-08-23 23:29:15 UTC
Package abrt-2.0.12-1.fc17, libreport-2.0.13-1.fc17, btparser-0.18-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.12-1.fc17 libreport-2.0.13-1.fc17 btparser-0.18-2.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2012-08-30 00:58:01 UTC
abrt-2.0.12-1.fc17, libreport-2.0.13-2.fc17, btparser-0.18-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.