Please move your ABRT bugs upstream

[Kevin Kofler]

Christoph Wickert wrote:
> I'm doing this for ~ 130 packages and it works for me.

Good for you. I have more important things to do than do triaging day and 
night, sorry.

> Of course it is a some work, but it's easier for 20 downstream maintainers
> to deal with 10 reports each a week than for a single upstream developer
> to deal with 200 bugs a week because his software is packaged in 20
> distributions.

It's easier for hundreds of upstream KDE developers to deal with their bugs, 
each in their area of expertise, than for our 7 core KDE packagers (and 1 
triager).

Getting all bugs moved upstream is the ONLY way we can deal with KDE bugs 
efficiently. Otherwise we'd end up like the kernel or X.Org X11 where we 
have tons of bugs in our Bugzilla which often never get fixed because there 
are several orders of magnitude more bugs than maintainers.

Thankfully, ABRT bugs are not so much a problem for KDE because ABRT catches 
only the stuff DrKonqi misses for whatever reasons (e.g. crashes in non-GUI 
apps; I hope KCrash will really get moved to libkdecore as has been 
suggested upstream recently, then DrKonqi will get those too). Normally, KDE 
crashes are caught by DrKonqi and filed directly upstream where they belong.

> I really wonder what you think a maintainer has to do. You say testing
> is not his job and taking care of bugs isn't ether. This leaves
> packaging. Sorry, but to me this is a 'fire and forget' attitude.

* Packaging new upstream releases in a timely manner.
* Filing them as updates wherever that makes sense (i.e. doesn't break 
anything).
* Fixing Fedora-specific issues.
* Backporting upstream bugfixes, if they're important enough to deserve 
backporting now. (If the bug is some trivial glitch which doesn't actually 
prevent the user from doing any work and the upstream release with the fix 
is coming in a few days anyway, it makes no sense to bother backporting the 
fix.)
* In some cases, backporting upstream features.
* If the software is dead upstream, fixing bugs is up to the maintainer, 
which makes such software a PITA to maintain. But where upstream is alive, 
upstream should be expected to fix bugs in the software they maintain!

> I already told you several times that I consider this useful. One could
> see if a crash affects this or that distro for example. If is affects
> distro A, B and C but not X and Y, one can start looking at what distros
> have in common and what are the differences.

Sorry, but I still don't see how this is 1. useful at all and 2. worth the 
high amount of extra work.

> gnash is an extreme example. How many reports do you get per week?

5 per week on average (I checked the last 10 weeks, there were exactly 50 
ABRT crash reports for Gnash). There's no way I can fix them all.

Let's be honest. I know that Gnash crashes all the time. Everyone familiar 
enough with Gnash knows it. I don't expect this to change any time soon, no 
matter how many bugs get filed upstream. For every crash they fix, a 
bazillion new ones pops up. No amount of turd polishing is going to fix that 
mess.

> And how many except of gnash?

21.8 per week (again, average over the last 10 weeks), and if it weren't for 
DrKonqi catching most KDE crashes and filing them directly upstream, it'd be 
much worse. For KDE, our triager deals with them by asking the reporter to 
file them upstream, just like any other KDE bug.

> Nevertheless the bug handling doesn't work any better at KDE. I have
> checked this checkbox (of course) and so far nobody had taken care of my
> bugs while I'd be happy to provide more data.

Well, some components in KDE could definitely use more attention. But it's 
impossible for a team of 8 people (the people with ACLs to the core KDE 
packages in Fedora) to take care of all issues all over KDE! In the upstream 
trackers, at least the components which are being actively maintained 
upstream get a fast response.

        Kevin Kofler