FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 02-12-2010, 01:15 AM
Nils Philippsen
 
Default ABRT unusable again

On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:
> On Sat, 2010-02-06 at 10:53 +0000, Leigh Scott wrote:
> > IMO ABRT isn't that useful as a lot of the reports don't include steps
> > to reproduce (I just close the bugs after a month if they don't respond
> > to the "needinfo" request).
>
> You can do it even sooner. If backtrace is unusable and there is no
> description whatsoever, then *this* user is not likely to bother
> to do anything to help you.
>
> > I believe ABRT shouldn't file a bug report unless it is filled in
> > properly.
>
> Sadly, this is impossible to achieve. Sure, we can
>
> if (description == "") yell("Fill the description dammit!");
>
> but then user might well enter description consisting of
> "I dont care" (or worse).

You're contradicting yourself here. First you say we should close bugs
without a description even sooner (like, immediately?), then you don't
want abrt to not file a report without a description. I don't see why we
should manually do the work abrt fails to do automatically -- while it
is automatable.

What strikes me as very puzzling is why abrt has this humongous dialog
instead of leading the user step-by-step through this... I know you just
changed the UI in a stable release. But doing it twice is twice fun ;-),
so why not use a wizard (taking the user by the hand, doing it step by
step...) and do it like this:

1. Check if the bug has been reported yet (via that abrt BZ id thingy).
If yes, ask user to review the description (in their browser?) and
eventually add any additional details (see below in step 3a. for hints
abrt could provide for that), then stop here. Otherwise continue.

2. Check that all debuginfos can be installed etc, then continue. If
not, tell the user that "important debugging data" can't be assembled
right now and a) if they would like to postpone the bug report, if you
assume that it's a temporary problem or b) "there's an update for
package(s) ... which are used by your application, would you like to
install them?", as this seems to be the most common case of debuginfos
not being available.

3a. Display wizard window. Ask users (politely!) for a description of
what they did before the crash happened:

"Please describe what you did before the application crashed. Provide as
much detail as you can, this is important for the person getting the bug
report to help you. If this is too much work for you right now, you can
make some notes about details that are hard to remember in this field,
click on "Postpone report" below

_Hints for filling out this form_

...

[Cancel report] [Postpone report] [Back] [Forward]"

The buttons would be visible on any page in the wizard, [Back] would be
insensitive here because it's the first step. "_Hints for filling out
this form_" would be a link which would open a help page going into much
more detail, e.g.:

"... If you didn't use the app for a long while, state that, but try to
remember what you did when you last used it. Please also describe what
else you did immediately before the crash. ..."

Also provide examples of good and bad descriptions in this.

3b. While the user fills out the description, abrt loads debuginfo
packages in the background. If the user is ready before all are
downloaded, display the usual progress bar.

4. Next wizard page. Display backtrace, ask for review and removal of
sensitive data like passwords. "You don't need to understand most of
this, but if you see data )like passwords) you would not like to be put
into the bug report (which may be seen by anybody), please replace it
with a placeholder (like '<password>')."

5. Last wizard page. Get confirmation for filing the bug report. "You
can review what will be submitted by using the Back and Forward buttons
at the bottom of this dialog." Fields for Bugzilla username and
password, pre-filled if we have that information already. "[ ] Remember
this information" checkbox.

If the user postponed this, they must have a means of continuing this,
so the applet may not be hidden in this case. While I'm at it, the
applet shouldn't flash forever, this breaks energy-saving measures (if
the user ignored it for a minute, they'll ignore it for an hour -- maybe
wake up it screensaver gets active, then inactive/unlocked).

In my opinion this would be much less intimidating to users and give us
bug reports where we can actually help instead of having to tell most of
them "sorry, too few info, can't help" right away.

Those who don't care enough to fill out the description probably won't
care enough to create a BZ account in the first place. If there are
trolls who would put nonsense into the description or worse, well those
could do that via web-based BZ as well. And they can be dealt with.

Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-12-2010, 07:49 AM
Jiri Moskovcak
 
Default ABRT unusable again

On 02/12/2010 03:15 AM, Nils Philippsen wrote:
> On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:
>> On Sat, 2010-02-06 at 10:53 +0000, Leigh Scott wrote:
>>> IMO ABRT isn't that useful as a lot of the reports don't include steps
>>> to reproduce (I just close the bugs after a month if they don't respond
>>> to the "needinfo" request).
>>
>> You can do it even sooner. If backtrace is unusable and there is no
>> description whatsoever, then *this* user is not likely to bother
>> to do anything to help you.
>>
>>> I believe ABRT shouldn't file a bug report unless it is filled in
>>> properly.
>>
>> Sadly, this is impossible to achieve. Sure, we can
>>
>> if (description == "") yell("Fill the description dammit!");
>>
>> but then user might well enter description consisting of
>> "I dont care" (or worse).
>
> You're contradicting yourself here. First you say we should close bugs
> without a description even sooner (like, immediately?), then you don't
> want abrt to not file a report without a description. I don't see why we
> should manually do the work abrt fails to do automatically -- while it
> is automatable.
>
> What strikes me as very puzzling is why abrt has this humongous dialog
> instead of leading the user step-by-step through this... I know you just
> changed the UI in a stable release. But doing it twice is twice fun ;-),
> so why not use a wizard (taking the user by the hand, doing it step by
> step...) and do it like this:
>
> 1. Check if the bug has been reported yet (via that abrt BZ id thingy).
> If yes, ask user to review the description (in their browser?) and
> eventually add any additional details (see below in step 3a. for hints
> abrt could provide for that), then stop here. Otherwise continue.
>
> 2. Check that all debuginfos can be installed etc, then continue. If
> not, tell the user that "important debugging data" can't be assembled
> right now and a) if they would like to postpone the bug report, if you
> assume that it's a temporary problem or b) "there's an update for
> package(s) ... which are used by your application, would you like to
> install them?", as this seems to be the most common case of debuginfos
> not being available.
>
> 3a. Display wizard window. Ask users (politely!) for a description of
> what they did before the crash happened:
>
> "Please describe what you did before the application crashed. Provide as
> much detail as you can, this is important for the person getting the bug
> report to help you. If this is too much work for you right now, you can
> make some notes about details that are hard to remember in this field,
> click on "Postpone report" below
>
> _Hints for filling out this form_
>
> ...
>
> [Cancel report] [Postpone report] [Back] [Forward]"
>
> The buttons would be visible on any page in the wizard, [Back] would be
> insensitive here because it's the first step. "_Hints for filling out
> this form_" would be a link which would open a help page going into much
> more detail, e.g.:
>
> "... If you didn't use the app for a long while, state that, but try to
> remember what you did when you last used it. Please also describe what
> else you did immediately before the crash. ..."
>
> Also provide examples of good and bad descriptions in this.
>
> 3b. While the user fills out the description, abrt loads debuginfo
> packages in the background. If the user is ready before all are
> downloaded, display the usual progress bar.
>
> 4. Next wizard page. Display backtrace, ask for review and removal of
> sensitive data like passwords. "You don't need to understand most of
> this, but if you see data )like passwords) you would not like to be put
> into the bug report (which may be seen by anybody), please replace it
> with a placeholder (like '<password>')."
>
> 5. Last wizard page. Get confirmation for filing the bug report. "You
> can review what will be submitted by using the Back and Forward buttons
> at the bottom of this dialog." Fields for Bugzilla username and
> password, pre-filled if we have that information already. "[ ] Remember
> this information" checkbox.
>
> If the user postponed this, they must have a means of continuing this,
> so the applet may not be hidden in this case. While I'm at it, the
> applet shouldn't flash forever, this breaks energy-saving measures (if
> the user ignored it for a minute, they'll ignore it for an hour -- maybe
> wake up it screensaver gets active, then inactive/unlocked).
>
> In my opinion this would be much less intimidating to users and give us
> bug reports where we can actually help instead of having to tell most of
> them "sorry, too few info, can't help" right away.
>
> Those who don't care enough to fill out the description probably won't
> care enough to create a BZ account in the first place. If there are
> trolls who would put nonsense into the description or worse, well those
> could do that via web-based BZ as well. And they can be dealt with.
>
> Nils

Hi,
Thanks for good hints, I'm already working on a wizard style gui for
ABRT, to walk the user thru the reporting proccess, so I'll definitely
implement some of you ideas into it.

Thanks,
Jirka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-12-2010, 08:42 AM
Till Maas
 
Default ABRT unusable again

On Fri, Feb 12, 2010 at 03:15:39AM +0100, Nils Philippsen wrote:

> What strikes me as very puzzling is why abrt has this humongous dialog
> instead of leading the user step-by-step through this... I know you just
> changed the UI in a stable release. But doing it twice is twice fun ;-),
> so why not use a wizard (taking the user by the hand, doing it step by
> step...) and do it like this:

For me the dialog works pretty well and I suspect a wizard would only
slowdown it. So if there is some wizard added, please make it optional.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-12-2010, 04:29 PM
Nils Philippsen
 
Default ABRT unusable again

On Fri, 2010-02-12 at 10:42 +0100, Till Maas wrote:
> On Fri, Feb 12, 2010 at 03:15:39AM +0100, Nils Philippsen wrote:
>
> > What strikes me as very puzzling is why abrt has this humongous dialog
> > instead of leading the user step-by-step through this... I know you just
> > changed the UI in a stable release. But doing it twice is twice fun ;-),
> > so why not use a wizard (taking the user by the hand, doing it step by
> > step...) and do it like this:
>
> For me the dialog works pretty well and I suspect a wizard would only
> slowdown it. So if there is some wizard added, please make it optional.

I guess the normal all-in-one dialog is simple enough that it can be
kept as an option.

Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-15-2010, 08:51 AM
Christoph Wickert
 
Default ABRT unusable again

Am Sonntag, den 07.02.2010, 14:16 +0100 schrieb Jiri Moskovcak:

> - ABRT uses the code from Dr.Konqui to rate the backtrace and doesn't
> allow user to send it if the rate is bellow 3 (the scale is 0-4), but
> the bug in GUI let user to send even the bad BT.

I think this bug should be fixed now in 1.0.6, but the rating doesn't
work. A backtrace with no debuginfo was rated 3 (while it should be 0 I
guess).

https://bugzilla.redhat.com/show_bug.cgi?id=565387

Regards,
Christoph

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-16-2010, 11:40 AM
Karel Klic
 
Default ABRT unusable again

On 02/08/2010 06:11 PM, Karel Klic wrote:
> On 02/08/2010 02:22 AM, Christoph Wickert wrote:
>> Am Sonntag, den 07.02.2010, 22:26 +0100 schrieb Karel Klic:
>> IMO all lists should be sorted by package owner. I own ~ 120 packages
>> and it is a quite lot of work to search all these packages in your
>> lists.
> I'll try to do it.

Both lists are now sorted by package owner:
https://fedoraproject.org/wiki/User:Kklic/ABRT_Duplicates
https://fedoraproject.org/wiki/User:Kklic/ABRT_Incomplete_Backtraces
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 09:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org