ABRT unusable again

Michael Schwendt mschwendt at gmail.com
Sun Feb 7 14:34:59 UTC 2010

On Sun, 07 Feb 2010 14:23:13 +0100, Stefan wrote:

> The question was if the package maintainer should
> be triggered first instead of upstream which increases the load for the
> package maintainer who might not be able to handle all of these requests
> in the end because it is not his/her full time job.

Well, that isn't straight-forward to answer IMO.

First of all, upstream may not be paid either for working on the software
_and_ on incoming problem reports. What sort of "support" and response
time can you expect from upstream in that case?

Secondly, the package maintainer should be informed about what is broken
with the chosen/packaged software release. Certainly you don't ask for
upstream to filter out *all* reports from all distributions, to return
distribution-specific ones into a dist's own bug tracking system, and to
work on incomplete backtraces or problems that aren't trivial to reproduce
in the absence of the original bug reporter. Depending on the software
quality it may be that upstream cannot handle all that either.

Fedora packages are not fire'n'forget releases. Even if you forwarded
every bugzilla ticket to upstream, you would still need to monitor the
status of the forwarded reports or fix issues yourself, provided that they
matter to you. Whether they should matter to you also depends on project
strategies and goals and whether Fedora wants to deliver added value. In
some cases, the product (or individual packages) may suffer from
insufficient contributor resources, and a single package maintainer
may not be enough.

> ABRT might point out software which
> needs more attention.

That is not its task. Bugzilla statistical queries could examine packages
for a high number of open/unresponded tickets, a growing number of
tickets closed by the bugzapper scripts at dist EOL, a low update
frequency, and a package owner who isn't responsive for other packages

Michael Schwendt
Fedora release 12 (Constantine) - Linux

More information about the devel mailing list