On Fri, 2011-01-07 at 15:29 +0100, Jiri Moskovcak wrote:
This is the list of feature to complete for ABRT 2.0, once this list is finish we'll done with 2.0. The list is probably not complete, so please add anything you think is missing. I'd also like to ask you to add some comments about how far the feature (you're working on is) and what it depends on, so I can then make it into nice roadmap...
= ABRT 2.0 Features (what we need) = ... /etc/abrt/conf.d/ directory (devels can drop there configuration for their packages) --> provide a way for maintainers to blacklist their packages without changes into abrt package
Let's perform a bit of brainstorming on this.
Fragment of current default /etc/abrt/abrt_event.conf:
# abrt-action-analyze-c needs package name, save package data first EVENT=post-create abrt-action-save-package-data EVENT=post-create analyzer=CCpp abrt-action-analyze-c EVENT=post-create analyzer=Python abrt-action-analyze-python EVENT=post-create analyzer=Kerneloops abrt-action-analyze-oops
A few ideas how to extend it to pick up config files from a subdir so that other packages can add/modify post-create event handling:
(1) [include] /etc/abrt/event.post-create.d/
(2) EVENT=post-create abrt-handle-crashdump -d "$DUMP_DIR" -e "$EVENT" -c /etc/abrt/event.post-create.d/
(3) EVENT=post-create for f in /etc/abrt/event.post-create.d/* do test -f "$f" || continue abrt-handle-crashdump -d "$DUMP_DIR" -e "$EVENT" -c "$f" || break done
Relative pros and cons: Proposal (1) - new directive "[include] DIR" or "include GLOB_PATTERN" - allows to statically determine whether a particular dump dir has any defined "post-create" event handler(s) - config file parser can walk included config files and find out whether there is a handler. For "post-create" event it's not that important, but for "report[_FOO]" events it is: client programs do this in order to determine which report events make sense for a particular dump dir. The importance of this depends on whether we envision packages to add their own configs with handling for *reporting* events (as opposed to "post-create" even and such). Do we?
Proposals (2) and (3) are similar: instead of making config parser more complex, they use the power of modularity which new event-based processing gave us. They both need abrt-handle-crashdump to be extended with -c CONF_FILE or -c CONF_FILE_OR_DIR option. Another useful extension is to allow action to be written in multi-line form, as shown in proposal (3). On the minus side, they might look ugly. Do they look ugly to you?
What else we might want/need? Consider the case when packages can add additional data-collecting steps, but they do not know *when* this data-collecting should happen - immediately after crash (post-create event) or at the point when user selects the crash for reporting ([re]analyze events)? Proposal (2) can handle this situation by "redirecting" one event to another, something like this:
EVENT=post-create abrt-handle-crashdump -d "$DUMP_DIR" -e collect-data -c /etc/abrt/event.collect-data.d/
, making it possible for admin to change when to do data-collecting by a single edit - changing EVENT=post-create to, say, EVENT=analyze.
Whereas proposal (1) can't do this, and needs even more syntax changes to make it possible.
That's all from me for now. Your thoughts on this? As a minimum, indicate which of proposals 1/2/3 looks best (or "least ugly") to you.