On Wed, Jul 16, 2014 at 11:59 AM, Jiri Eischmann <eischmann@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.