ABRT frustrating for users and developers

[Jiri Moskovcak]

On 01/17/2010 05:57 PM, Christoph Wickert wrote:
> Am Sonntag, den 17.01.2010, 15:53 +0100 schrieb Jiri Moskovcak:
>> On 01/16/2010 04:01 PM, Christoph Wickert wrote:
>>> I know that APRT is still very young technology, but after 2 months it's
>>> time for a interim conclusion. For me the conclusions are:
>>>
>>> Pro:
>>>
>>>         * abrt is a help for developers: I received one positive feedback
>>>           from a developer: The backtrace looks "interesting" but cannot
>>>           be fixed without a major rewrite of the app.
>>>
>>>         * abrt helps to fix bugs sometimes: So far abrt helped me to fix
>>>           three crashes in two apps (in Fedora and upstream).
>>>
>>> Con:
>>>
>>>         * Unfortunately 3 out of ~ 40 reports is not a good percentage.
>>>
>>
>> I'm open to any ideas how to improve this.
>
> Sorry, I have no idea, except:
>       1. Don't accept incomplete backtraces.
This is to do, but what should be the threshold? should we accept only 
backtraces generated with all required debuginfo?
>       2. Make a comment and the description how to reproduce the bug
>          mandatory.
OK, will do.
>       3. Add a timestamp to the backtrace because many people submit
>          their bugs later and they don't recall when it happened. This is
>          important for me, I need to know it it happened before or after
>          a certain update.
OK
>       4. Add n-v-r of the affected packages, so it is obvious if people
>          submit old bugs.

Do you mean NVRs of libraries the crashing program was using?

>       5. Instead of hashes the missing debuginfo packages should be
>          listed with n-v-r, so people can install them manually.
>
This could be a problem. ABRT determines the required debuginfo package 
using build_id. It calls yum --enablerepo=*debuginfo* --quiet provides 
/usr/lib/debug/.build-id/bb/11528d59940983f495e9cb099cafb0cb206051.debug 
and I don't know any other way how to map build_id to package name if 
yum fails.

Jirka

>>>         * As already pointed out by Michael Schwendt some time ago, there
>>>           were some good traces in the beginning but then they became
>>>           unusable. Starting with abrt 1.0.2 it got better again but I
>>>           still get bogus reports sometimes.
>>>
>>>         * As a maintainer abrt causes a lot of work. You have to respond
>>>           to the tickets, ask for details, explain how to install
>>>           debuginfo manually and tell people that their
>>>
>>
>> How this differ from any other bugs? ABRT just helps users to report
>> bugs so we get reports even from users who wouldn't bother otherwise.
>
> The difference is that most of these users don't bother to write a
> simple comment, to install debuginfo or respond to the bugs they filed
> with ABRT at all. Another huge difference is the workload for me.
>
>>>         * abrt is frustrating for maintainers: Upstream refuses to accept
>>>           the backtraces generated by abrt. Happened to me three times.
>>>
>>
>> If the backtrace is complete then there is no reason why upstream
>> shouldn't accept it, but if there is a problem with installing debuginfo
>> then there is nothing ABRT can do (except to prevent user to send a
>> report, but what's the threshold here?).
>
> Does ABRT prefent them from sending these reports? I don't think so
> because I'm still getting bogus reports with ABRT 1.0.3.
>
>>>         * abrt is frustrating for users: Today I received my first "No
>>>           need for a reply...I will stop submitting tickets."
>>>
>>
>> They can always remove it and go back to previous reporting mechanism
>> using bugzilla web form.
>
> Most of them wouldn't do that, but people who submit something with ABRT
> are disappointed that their bugs are getting closed. If you don't do
> something, you cannot be disappointed.
>
> Regards,
> Christoph
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmoskovc.vcf
Type: text/x-vcard
Size: 126 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100118/c498476a/attachment-0001.vcf