In <[🔎] email@example.com>, Lisandro Damián Nicanor Pérez Meyer wrote: >On Mié 03 Jun 2009 11:30:00 Benjamin Eikel escribió: >> thank you for that hint. I added the information about the upstream bug >> to the Debian bug report. >> One general question about reporting bugs in KDE related Debian >> packages: Is it desired to report bugs (which do not seem to be related >> to the packaging) in the Debian BTS at all or should I simply report >> that bug upstream and do not bother the Debian maintainers? >There has been some interesting discussions about this. From my POV, it is >(almost) useless to report an upstream bug here if the bug is reported > first upstream. 1) KDE/Qt has a lot of bugs. Maybe I just notice them more, but it seems to be like KDE/Qt has more bugs per line of code than any other team in Debian. I don't think this reflects a bad job on the part of the Debian KDE/Qt team -- most of the bugs are upstream issues. 2) As a result of this, anyone seriously engaged in reporting and tracking KDE/Qt bugs needs to follow the upstream bug tracker(s). [I don't think Qt's bug tracker is public, but I could be wrong.] 3) Since anyone reporting/tracking bugs needs to follow all the bug trackers, having a bug reported on both doesn't give them any additional information. In an ideal world, Debian users would not need to deal with bug trackers other than the Debian BTS. This is the optimal user experience and the all DMs should have this as a goal. However, the KDE/Qt team is way overworked and I can't pitch in much time, so I'm gonna cut them some slack; I hope others will too. If it is already reported upstream, and it is not of rc-severity don't bother filing it on the Debian BTS. It is already being tracked by the right people. If it is of rc-severity, even if it is reported upstream, report it on the Debian BTS so that it can be tracked for the Squeeze release and can hold up auto-migration from Sid if you caught it early enough. If you can't find it in any bug tracker and can easily replicate it on a non-Debian-derived distribution, file it upstream. (If it is rc-severity file it with Debian too and mark it forwarded.) If you can't find it in any bug tracker and can't easily replicate it on a non-Debian-derived distribution, guess. The KDE bug tracker as a resolution of "downstream" and the Debian BTS has the "upstream" tag and "forwarded" status, so even if you guess incorrectly, the developers and maintainers should be able to track the bug effectively. >But is the reporter wants the bug to be on both BTSs, and forwards the bug >correctly, I don't see any problems. There's still a little extra load on the maintainers' having to track the bug to determine when/how to close it. >Please, do not take my word on this as final. And the real way to get not- >packaging bugs solved is still upstream. Absolutely. It's not the maintainers' job to *fix* non-packaging bugs, although user do appreciate it. It is the maintainers' job to communicate the bugs to upstream and track fixes for inclusion in Debian. -- Boyd Stephen Smith Jr. ,= ,-_-. =. firstname.lastname@example.org ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/  I love KDE, really. It's wonderfully powerful and customizable. However, I now realize I'm subconsciously working around at least a half- dozen bugs, even in KDE 3.5.9. Plus, I don't "exercise" much of the KDE code; I'm a simple user.  Yes, it is a "bug in Debian", so this advice is not strictly in line is the text of policy. However, I think it is in the spirit of Debian; it is be most efficient way to optimize the Debian users' experience.  Oooh! You have a non-Debian-derived distribution available? Please, please help triage the existing KDE/Qt bugs and forward the ones upstream that you can. It possible that many of the existing bugs aren't packaging issues.  This is different from my opinion last time and I'm not that attached to it. I still think that if you have no idea what to guess you should file with the Debian BTS; it's the maintainers' job to forward bugs that need to go upstream.
Description: This is a digitally signed message part.