ABRT unusable again

Stefan Schulze Frielinghaus stefan at seekline.net
Sun Feb 7 16:55:02 UTC 2010


On So, 2010-02-07 at 15:34 +0100, Michael Schwendt wrote:
> 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.

Hmm yeah. I see the problem. It would even get worse when e.g. some
patches are applied to the package, then upstream couldn't even debug
properly.

Nasty situation ;-) I will think about it. Hopefully it was not too off
topic.

Thanks for letting me know,
Stefan



More information about the devel mailing list