ABRT?

[Elad Alfassa]

On Wed, Jul 16, 2014 at 11:59 AM, Jiri Eischmann <eischmann at redhat.com>
wrote:

> I think it's important to distinguish two things ABRT does:
>
> 1. it makes (or at least it is supposed to) it easier to report bugs to
> bugzilla.
>
> Lately ABRT is very slow to report bugs even if you ignore the UI
problems. I've had reports fail with an unexplained error, and I had issues
where ABRT simply deleted the problem directory when I was in the middle of
writing a description. It clearly doesn't work as well as it should

> 2. it makes so called ureports that are used for the statistics and
> weighting problems.


> ad 1) I think ABRT offers two ways to create backtraces etc. Either on
> their server or on your machine. AFAIK ABRT started preferring the
> former option because users don't have to install all the debug tools to
> report a problem, but if their server is overloaded it may take ages to
> create a bug report.
>

Some users have extremely slow upload speeds, so uploading a 100MB core
dump takes ages.
Downloading the debuginfo is also a problem for people with slow download
speed.

Fedora executables and shared objects are compiled with a minimized form of
debuginfo. It allows creating a simple backtrace even when you don't have
the huge -debuginfo packages installed, when the only downside for this
case is that you'll not have source line names, only symbol names and the
name of the shared object they came from.

I think that if we want to improve ABRT's UX, we need to get rid of the
retrace server AND the debuginfo downloading, an generate the backtrace for
the bugreport without these.
The backtrace will take less than a minute to generate (in most cases) and
is better than nothing. Users won't have to wait HOURS for the debuginfo to
download or the coredump to upload just to be informed the reporting
"failed".


>
> ad 2) This is not slow at all. ureports are created and uploaded within
> seconds.
>

> I agree with Christian. We should not remove ABRT completely. The
> retrace server is an important tool for many developers. If reporting
> bugs is broken, then we may disable it and let ABRT create only the
> ureports until it's fixed. On the other hand, we would lose links to
> actual bug reports in bugzilla. I also agree that there needs to be
> something done with the UI which is frankly quite terrible.
>
>
Until ABRT's UX and UI improve, I think including it in the default install
makes no sense. From my experience with ABRT it's usually easier to open a
bugzilla bug manually than going through the long, slow, annoying process
of ABRT
reports. I'm honestly surprised we get many ABRT bug reports because the
process is simply too annoying to expect any regular user to actually
complete it.

Also, I think the amount of useless ABRT crash reports, or crash reports
ignored by packagers is much higher than the reports that are actually
looked into and fixed. And it makes sense, because packagers are usually
not developers and wouldn't know what to do with most of the crashes, and
moving countless of crash reports upstream is simply too much boring work
for packagers to do. Like said elsewhere in this thread, ABRT should have
the option for packagers to define which bug tracker to use for crashes.
GNOME crashes should be reported the the GNOME bugzilla, KDE crashes should
be reported to the KDE bugtracker, etc etc.

I think we need to remove ABRT by default in F21, or limit it to sending
ureports without any UI or notification, and work to make the UI and UX
better so we can reconsider ABRT's inclusion in F22.
Ideally, the process should take less than 5 minutes for most bugs (and the
number of steps in the "wizard" should be greatly reduced), and the
notifications should be made less annoying (see the designs in the GNOME
wiki).


-- 
-Elad Alfassa.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20140716/a5b51c0e/attachment.html>