Significant drop in ABRT reports in F22

[Marek Brysa]

Hi Michael,

thank you for pointing out these issues. I tried to answer most them inline.

----- Original Message -----
> From: "Michael Catanzaro" <mcatanzaro at gnome.org>
> To: "Discussions about development for the Fedora desktop" <desktop at lists.fedoraproject.org>
> Sent: Friday, May 15, 2015 11:26:47 PM
> Subject: Re: Significant drop in ABRT reports in F22
> 
> Surely gnome-abrt does not look as bad as before, but I do not agree
> that it has improved "a lot." Automatic crash reports are very
> valuable, but they will work just fine without gnome-abrt. Bugzilla
> reports are even better, but the UI for this is just not good enough.
> Continuing to ship it makes us seem less professional.
> 
> To be clear: I'm not opposed to continuing to ship the system service
> that reports crashes automatically. Nor do I propose any changes for
> F22; it's way too late for that. But I do think we should remove gnome
> -abrt from the default install in F23.

By that time we should have DBus API even for Bugzilla reports and as Richard mentioned, it should be fairly easy to write a completely new GUI to perfectly fit Gnome's UX. The wheels are in motion, it's just that our team is moving a lot of them. We certainly welcome and appreciate any contributions - send patches! :-)

> 
> On Fri, 2015-05-15 at 16:41 +0200, Richard Marko wrote:
> > Sure. It's rocket science to make a GUI according to Gnome HIG, cause
> > it
> > shouldn't have any buttons or features. 2-3 years? I can and I will
> > write an Qt app for ABRT in 2-3 days when our DBus API stabilizes.
> > 
> > I'm wondering what according to you is "in shape" as in my experience
> > most Gnome apps went downhill in terms of usability, features and
> > overall look.
> 
> I'm sorry that my last mail was too harsh.
> 
> I find gnome-abrt to be very frustrating to use. Here are some problems
> I see:
> 
> * Random italic and bold text in the "This problem has been reported,
> but a _Bugzilla_ ticket has not been opened" label.
> * Problems should not disappear from the list with no indication as to
> why. (Removing core dumps to free disk space is good. Hiding the
> history of crashes completely when they're removed is not.)

This is a problem that needs to be addressed in the back-end. We'll take it into account when doing the new DBus API.

> * Problems should not disappear *while they are currently being
> reported* as that leads to a confusing error message.

Same as above.

> * The list box on the left is not wide enough, resulting in a small bit
> of horizontal scrolling.

The width of the list box on the left has the been calculated precisely according to the design valid at that time:
https://wiki.gnome.org/Design/Apps/Oops
https://github.com/abrt/gnome-abrt/commit/046c730c293c5981a09af70ae769183c0a07034a
Resizable width was explicitly rejected by designers.

Granted, in Allan's most recent design, the list seems wider and we'll take a look at it.
https://github.com/abrt/gnome-abrt/issues/103

> * Above the list box, there is a distinction between My (what?
> crashes?) and System (what?) crashes that's not relevant or meaningful
> to users.

This is again a problem in the back-end.

> * System crashes mysteriously disappear from the System list and appear
> in the My list while being viewed.

This will be fixed with reworked D-Bus API.

> * I can click the Report button on problems that have already been
> reported to both the ABRT server and to Bugzilla. Nothing happens when
> I do.

You should be able to report a problem as many times as you wish because you can send a report via e-mail or you can upload the problem data etc.
If "Nothing happens when I do.", then you've found a bug.

> * The word "ABRT" appears in the UI. What's an ABRT? (The string ABRT
> appears in several other places throughout the UI, and can be replaced
> by "Problem Reporting.")

Could you please create and issue for that?

> * The menu allows launching both Preferences and ABRT Configuration,
> which are separate(!) dialogs.

We are going to merge those dialogs, but it's not high in our priorities.

> * The window title of the Preferences dialog is Configuration. The
> window title of the ABRT Configuration dialog is Problem Reporting
> Configuration.
> * Both dialogs use the action area (buttons across the bottom of the
> dialog), which is deprecated. The dialogs should use a header bar and
> put the buttons there.
> * The ABRT Configuration dialog uses color question icons. They should
> be symbolic icons.
> * The Preferences dialog just needs to be removed. The huge lists of
> Workflows and Events are way too detailed. This looks good for a power
> user tool, but apps we ship by default should be simple to use.

I think we need to go over why each one of these options should not be configurable.

> Hopefully we don't need to go over why each one of these options should
> not be configurable, except for Bugzilla account details.
> * If I click Configure on an item in the preferences dialog (e.g.
> Report to Fedora), the notebook items are too wide for the window, with
> horizontal scrolling. They start out scrolled to the right, so the
> leftmost portion of the first letter of each preference is cut off.
> * Clicking the Report button opens a new window. The application should
> use only one window.

Is that something in Gnome's HIG? Anyway this is because we need to launch a separate libreport process for reporting. It should be doable with a single window using the new DBus API.

> * There is too much blank space before the text Add a screencast.
> * Add a screencast launches a confusing tool with Stop, Record, Select
> window, and Close buttons in the bottom-right corner of the screen. It
> should use GNOME's professional built-in screen recording functionality
> instead (Ctrl+Alt+Shift+R).

ABRT is not a GNOME-only project. The tool provides a bridge between Desktops and libreport. GNOME is not he only Desktop we need to support.

> * Possible sensitive data is a false positive 99% of the time. Jakub
> added lots of filters to try to reduce these, but it's still always
> wrong.

Please report false positives so we can do assisted learning :-)

> * The UI shouldn't mention "Fedora Contrib group members" because
> that's meaningless to users.
> * environ, cmdline, backtrace, hostname, comment and reason should not
> have horizontal scrolling. This makes them all extremely difficult to
> read. 

I believe this is a matter of preference. For me, wrapped lines are less readable.

> Attempting to scan a backtrace of any length for personal data is
> a chore, since I have to scroll down a bit, then scroll all the way
> across to the right, then scroll back to the left, then scroll down a
> bit more, then scroll all the way across to the right....

You don't need to scroll, you can jump by search result.

> * The Forward button is a text button in the bottom right. It should be
> an icon button in the top right of the header bar.

This can be addressed in reporting UI using the new DBus API.

> * Search -> Find. Search should be activated automatically by typing,

This works in the problem list. Or do you mean while reporting?

> filter (hide) content, and have an icon button in the header bar. We
> use Find for jumping around between content.
> * Pressing Ctrl+F should start a Find.
> * Most importantly, reporting very frequently fails with the message
> that the backtrace is unusable. That should almost never happen. If
> sufficient debug info isn't available, it shouldn't be possible to
> start a report.

The coredump goes through a sanity check when ABRT generates a core backtrace. There is unfortunately no way of telling whether full retracing will succeed unless you actually try it. Please note that programs crash because they reach an unexpected state so there is a significant probability that so much memory is corrupted that the retracing simply fails.

> 
> I don't intend to file problem reports for these (although I already
> have for a few). There are just too many issues. The landing screen
> looks mostly good. The rest of the tool does not.

As I said, the reporting "wizard" is part of libreport and it will be much easier to work on it once the new DBus reporting API is in place.

> 
> > Retrace server is something different and there's no reporting to
> > retrace server - retrace server (surprise) does retracing of core
> > dumps
> > to generate micro reports sent to faf.
> > 
> > https://abrt.readthedocs.org/en/latest/howitworks.html
> 
> Thanks for the correction. What does faf stand for?

FAF stands for Fedora Analysis Framework.
https://retrace.fedoraproject.org/faf/
It lives on the same machine as the retrace server because they can benefit from each other's data. Right now, we're internally discussing an even tighter integration of the two.

> 
> > If you ever talked to ABRT developers about these sort of things you
> > would know that there's integration ongoing to use tooling that
> > systemd
> > provides (both coredump hook & journald) so it would be possible to
> > use
> > coredumpctl and abrt alongside.
> 
> I actually have many, many issue reports, about half or so of which
> were promptly fixed by Jakub. In particular, one related to
> coredumpctl:
> https://github.com/abrt/abrt/issues/835
> 
> I believe we've also discussed it on this list in the past. It's a
> killer feature that we should enable ASAP. The first time I typed
> 'coredumpctl gdb' I knew that I would never be able to seriously use a
> distro without systemd again.

This is a useful tool and ABRT can do the same thing and more, it can even automatically download debuginfos:
https://github.com/abrt/abrt/issues/934
We're going to introduce the tool very soon.

In the meantime, you can enable abrt-journal-core that makes ABRT use coredumpctl:
# systemctl disable abrt-ccpp
# systemctl enable abrt-journal-core
# systemctl start abrt-journal-core

The only downside is that the coredump is saved twice - once in journal and once in ABRT's dumpdir. This is the reason it's not enabled by default, but we're going to solve it in the future.

> 
> > By tremendous cost you mean you can't use fancy coredumpctl gdb
> > command
> > but with little effort you can write a simple wrapper around abrt-cli
> > that does the very same thing.
> 
> Hm, "tremendous cost" was too hyperbolic, sorry. I want coredumpctl
> working out of the box, but it's probably more important to have ABRT
> by default.
> 
> >  I agree abrt-cli is not the most usable
> > or intuitive tool but I haven't seen an RFE from you about its
> > missing
> > features. So why you are bashing our project instead of trying to be
> > constructive?
> 
> I don't care about abrt-cli because it's a CLI tool that most users
> will never notice or deal with. I don't think I've used it before ever.
> I do care about Problem Reporting (gnome-abrt).
> 
> Michael

Marek