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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
