On 07/08/2010 05:17 PM, Denys Vlasenko wrote:
On Thu, 2010-07-08 at 14:27 +0200, Karel Klic wrote:
> On 07/07/2010 03:28 PM, Denys Vlasenko wrote:
> This config file can be used as an effective way how to support 3rd
> party plugins: custom reporters, custom collectinfo steps, custom shell
> scripts -- whatever a power user or admin wants. It allows a good degree
> of customization by env. variables and parameters, but it does not allow
> everything we want to offer to GUI and CLI users on the desktop.
Can you describe what we want to offer to GUI and CLI users?
This needs to be described (written down),
so far it exists only in our heads.
I was under impression that we want *mostly automated* bug reporting.
Seems like you want more like *manual bug reporting* instead. For
example, it seems you want reporting to be completely customizable on
the user side. This is news to me.
I was under impression that we wanted to allow submitting bugs directly
to various upstreams depending on package, configure various ABRT
options via GUI...so yes, allowing more experienced users to do manual
bug reporting.
If one of the goals is to keep ABRT simple, then my notes are off-track.
I was thinking about supporting a lot of complex end-user features --
not about simplicity.
So, what are our goal(s)?
Before we can meaningfully discuss the design, we need to discuss what
we want to achieve, which use cases.
> In
> other words: abrt-handle-crashdump would still support all the stages as
> proposed, but we would use them only for stuff which does not need user
> configuration and intervention.
>
> So we would not use it for our Bugzilla plugin, bug status updates and
> so on, but if someone want to write a custom collectinfo/reporter, or
> enable our reporter this way, the possibility is there and it is usable.
> The plugin entered here just cannot have a GUI settings, custom wizard
> step in the GUI,
In general, I feel that writing things with "custom wizard
step in the GUI" _across dbus link_ is an exercise in self-inflicted
PITA. It is hard enough to write such things even without inter-process
communication, throw in that and you have major programmatic disaster
on your hands. Endless hard to debug bugs. A lot of frustrated users.
I agree completely. Custom wizard steps should stay in abrt-gui, not
delivered over dbus. Maybe I explained it wrongly, sorry.
> bug status refreshing, and custom CLI stuff like "ask
> for password if it's missing", but you can write a plugin which does a
> lot of things with the debugdump directory and that's it.
>
> We can handle the configuration of our complex, GUI/CLI-interacting
> plugins with periodic background refreshing and whatever else will be
> needed closer to the processes which uses them.
What periodic refreshing? I don't understand.
Bug status refresh. User reported 3 bugs to Fedora Bugzilla and 1 bug to
KDE Bugzilla and 1 bug somewhere else. He wants to know when the bugs
were fixed, closed, updated. abrt-gui displays the bug status and checks
for status changes in background (periodically refreshes the local
status information).
Well, maybe it does not make sense to do it periodically, it is probably
enough to do it after abrt-gui startup.
> It would allow us to
> provide greater degree of customization (as expected by GUI users, and
> differently by CLI users). Reporting and collectinfo can be moved to
> GUI, CLI and abrtd (=autoreport).
1. I don't understand what you mean by (=autoreport).
Automatic upload of kerneloopses to some site using kerneloops reporter.
Automatic upload of crashes to some FTP, with the backtrace, SOS report etc.
2. How exactly do you propose to move reporting and collectinfo to
GUI?
Reporting:
abrt-gui allows user to select where he wants to report the bug (=to
select reporter; as it is now). The reporter list includes all enabled
Reporter plugins which are allowed for certain crash.
The wizard is assembled depending on which reporter user selected. There
are some default steps for reporters "unknown" to GUI, and some
additional steps for "known" reporters. For example if Bugzilla is
selected and the settings do not contain Bugzilla login and password, a
page to fill Bugzilla login and password configuration is added to the
wizard.
When all the input from user is gathered, GUI sends a message
"ReportHook" to abrt-dbus. It starts abrt-server, which runs
abrt-handle-crashdump "report" callback/hook. GUI receives some
feedback, displaying it to user.
Then the GUI sends "Report" message to abrt-dbus. The message contains
some parameters, namely the name of the report plugin to be run, and
maybe additional parameter for "known" reporters. Those additional
parameters will be appended to the command line when abrt-server calls
the plugin (e.g. --login=ddd --password==ddd).
> The only action we need from
> abrt-handle-crashdump is to mark the crashdump as reported (e.g. call
> `abrt-handle-crashdump DUMPDIR --mark-as-reported` via abrt-server), and
> store some information (abrt-handle-crashdump DUMPDIR --store
> "bugzilla_id" "560874" --store "bugzilla_status"
"NEW" --store
> "bugzilla_url" "http://").
That's what I was talking about: simple operations suddenly morph
into god-awful, complex things. In this case, you spawn entire process
in order to add a single flag to crash dump. Care to imagine how many
lines of code that would be, on both sides? fork, exec, error checks,
command line parsing... how many possibilities to have bugs? leaks?
Yes, I know.
One solution is to do this directly in abrt-server, as suggested by Jiri.
> GUI would store its enabled reporters and their settings in
/etc/abrt/
> and GConf, CLI in /etc/abrt/ and ~/.abrt/, abrtd autoreporter in
> /etc/abrt/.
What is abrtd autoreporter?
Automatic upload of kerneloopses to some site using kerneloops reporter.
Automatic upload of crashes to some FTP, with the backtrace, SOS report etc.
> We can later decide to support custom GUI for plugins, but
> we can implement it in the GUI (as a plugin to GUI, not to the ABRT core
> system). The same thing with the CLI.
>
> GUI would run the plugins at is sees fit (for example Jiri can decide to
> refresh Bugzilla statuses every 20 minutes in GUI, so he sends a
> hardcoded request "RefreshBugzillaStatuses" to abrt-server via
> abrt-dbus, and abrt-server runs `abrt-bugzilla DUMPDIR --refresh-status`
> for every crash which has a bugzilla_url and bugzilla_bug_id in the
> DUMPDIR).
>
> So the logic deciding which reporters and which reporter settings are to
> be used with certain crash would be in the GUI and CLI.
Complexity, complexity, complexity. I don't like complexity.
Why do we have server-side configuration then, at all,
if we then talk to client side about every setting
and every option?
I see no other option *if* we want user to change things from GUI.
What I propose is to move most of the configuration from server-side to
client-side.
Let's just copy entire crash dump to user side, and let it deal
with it
*locally*, not *across dbus and god know what else*. Bingo. No abrtd,
abrt-server, no IPC needed. It's all in ~/abrt/spool/CRASHDUMP dir.
Very good idea. IMO abrtd would still be needed.
Where is the catch?