----- Original Message -----
I thought it would be a good idea to somehow indicate that the
is completely handled (reported & commented). There were complains about
"Report" button enabled for already reported problems. Should I make
"Comment" button always enabled?
If it's possible to add new comments, yes.
> The process to skip commenting the first time is
> also sub-par. Given that the window is only there to show progress, maybe
> doesn't need to be there at all, and progress can be shown in the main
I am going to be completely honest with you: I want/need/have to reuse
the reporting window for several reporting work-flows because we have
one for Fedora (ABRT Server/Bugzilla), SELinux AVCs, Anaconda
(Bugzilla/Upload), RHEL and another distro in the near future.
I don't see what is, or should be different for the user about reporting
SELinux AVCs to Bugzilla, reporting Anaconda traces to Bugzilla, or reporting
crashers to ABRT.
> Are you after a UI review after that?
You are the reviewer :) Thank you very much indeed!
through to 67, to start with.
> > > One of the
> > > problems of having to input comments before the report is done is still
> > > there,
> > > and users still need to wait in front of the dialogue when reporting
> > > bugs
> > > against the ABRT server.
> > If you click "Report" in the notification bubble, no input is
> > and the reporting finishes immediately.
> Why is the work-flow different in this case?
Our vision is the following:
The notification bubbles:
- fast and simple reporting for users who don't want to go through the
full reporting process but want to let maintainers know about crashing
- for advanced users, they know the purpose of "Automatic Bug
Reporting Tool", who wants to participate in the bug resolution process
> Why would the user want *not*
> to report the bug?
OK, I wasn't precise, the reporting finishes immediately after sending
> Either do it automatically, or simply cache it all so that
> they can be reported by hand later, in the UI.
> > If you click "Report" in the GUI, the reporting window allows you to
> > provide a description, informs you about processing and tells you that
> > the reporting is done. The workflow is almost the same as the workflow
> > for New Report in Normal mode at:
> > https://wiki.gnome.org/Design/Apps/Oops
> I don't see any windows besides the main window in those mockups. The
> "add comment" variant is only there for developers.
Although I would really love to make ABRT's workflow completely the
same, I cannot do it because I need to reuse the reporting window for
other work-flows (Fedora, SELinux, Anaconda, RHEL).
That's really not a good enough reason for not wanting to change it.
> > > I also note that the core dump uploading, which gdb
> > > against,
> > Pardon? I am not sure I understand you. Where gdb engineers advised such
> > a thing?
> The gdb engineers, as well as security engineers, I talked to thought it
> was a bad thing for the core dump to even travel to a remote machine. The
> remote gdb could be vulnerable to a carefully crafted core dump,
> gaining access to the server, and also other user's core dumps.
> Even if the core dump generation using gdb on the remote server is secure,
> other services that it offers could be compromised and attackers could
> harvest passwords and other data from the core dumps.
ABRT warns users before uploading core dump and they can generate
backtrace locally if they have concerns about security.
Warning users doesn't make the retrace server secure. And there's currently
no other ways to generate a backtrace with full debuginfo.
> > > is still there for all the reports sent to the ABRT
> > No, the new workflow doesn't upload the core dump. If ABRT uploads the
> > core dump, it is a bug or you don't have Shortened Reporting ON:
> > https://github.com/abrt/abrt/wiki/Configuration#shortened-reporting
> Right, but that's still available when doing "shortened reporting
Yes, exactly. And GNOME user will do "Shortened reporting ON" by
Why wouldn't other users want to make use of the "shortened reporting"?
> I don't understand how one would switch between those 2
In the ABRT Preferences window. See:
As I mentioned before, I'm not sure why users wouldn't want to have this feature
on, all the time.
> or how they might know the difference.
It will be documented in the ABRT Preferences window, on the online
documentation and in man pages.
I still don't understand why we want to make this an option, so I'd like to know
the difference now :)
> > > Finally, I'd still prefer a way for the stack
traces with mini-debug
> > > that
> > > should
> > > already be available on the system to be uploaded without interaction.
> > > Full
> > > debug
> > > traces could be sent out as additional information to those reports
> > > (whether they
> > > end up in Bugzilla or just on the ABRT server).
> > Yes, if you use the notification bubbles for reporting, then ABRT works
> > as you describe. You can also enable the Auto-reporting to get rid of
> > necessity to click "Report" button in the notification bubble:
> > https://github.com/abrt/abrt/wiki/Configuration#autoreporting
> > The new workflow disables Bugzilla (and all the tings before opening a
> > new Bugzilla bug) when Shortened Reporting is ON for the reporting
> > process started from the GUI.
> This should probably be integrated in the Privacy Settings of the desktop
> of being in the bug reporting application's preferences.
Sure, what should I do to get this done?
I have attempted to develop a custom ABRT panel for control-center but I
That's because, as I said above, and 2 years ago, it should be integrated into the
Privacy panel, and it should only configure how to capture crashes (not at all,
locally only, or report them automatically).
Adding something like ABRT's Preferences to gnome-control-center is out of the