view filters in korganizer do not work

[linex83]

Binary package hint: korganizer

The application of view filters does not have any impact on the displayed todo list. I created a filter "open and active" (for uncompleted and active todos), but when I select the filter using View->Filter->"open and active" (or via the sidebar), nothing interesting happens. The window title bar even says: "Calendar - <No filter> - KOrganizer".

I am using Ubuntu 8.10 32bit, with the latest updates installed (2009-01-24). KOrganizer version ist 4.10. I run korganizer in GNOME.

This bug is quite annoying, since it basically makes korganizer unusable.

[Harald Sitter (apachelogger)]

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. While we appreciate your issue, it would be better if it was tracked at https://bugs.kde.org, so that the KDE developers can deal with this speedily and have direct communication with you as the reporter for more effective debugging.

Thanks!

[linex83 (linex83)]

I'm sorry, but this does not make any sense. Very few bug reporters will take the trouble to report bugs in multiple bug trackers. The end user should perceive Ubuntu/Kubuntu as a linux distribution and not as a gathering of thousands of packages and at least a few hundred different possible bug trackers.

Furthermore it took 18 month to get the info that packaging is not resposinble for this problem. Assume I would report this 18 month old bug to KDE - who would care about an 18 month old bug? Also it would probably take a few more month until it could be processed by KDE developers, making the bug even older and outdated by then.

It has nothing to do with you Harald, I am thankful for your reply, but you will surely agree that this Ubuntu/Kubuntu policy dealing with bugs does not make any sense. In my opinion Ubuntu/Kubuntu should either integrate some KDE developers or find an easy way to forward bug reports to them, such that the end user and bug reporter does not have to deal with it.

[Harald Sitter (apachelogger)]

Well, yes, but now. Automatic forwarding will not make sense, because a bug without someone who is affected by that bug does not make much sense because a developer will lack feedback if he needs it, rendering the bug a waste of time, because despite the fact that no one will be able to give any additional information it still shows up in lists and needs to be checked every once in a while until someone finally decides to close it because of pointlessness. Automation is not the solution at all.

What does make no sense is that I have to close bugs that no one looked at for 18 months because 2.5 people are looking after some 50 packages with some 5000 bugs a year.
It is not a problem of policy or motivation or automation, it is not even a problem of plain developer resources. It is a problem of people not giving a crap about getting bugs triaged [1], well maybe not even that but that triaging bugs is incredibly pain full and takes an incredible amount of time.
An issue to which the solution seems surprisingly simple, and yet so difficult -> get more people to work on bugs.

So, to get back to the original problem.
You cannot just automate forwarding since this will result in dead reports with possibly very unrelated information (maybe you noticed that the various tools in Ubuntu to report bugs attach loads and loads of additional information of which 1% is maybe of use). So you need a lot of people to take care of this. And here is an assumption from me that might sound a bit drastical: if someone who reports a bug is not willing to forward it to KDE, which takes maybe 15 minutes the very first time, then I would say that the bug is clearly not important enough to even be tracked. If the reporter, the person who should theoretically care most about getting this issue resolved, does not care enough to invest the time that is necessary to get it resolved...

The big picture of the policy is as follows: there are way too few people who are triaging bugs, but way too many bugs, of which way too many are really bugs in KDE that ultimately need to be resolved in KDE's source anyway.
So by generally sending KDE bugs to KDE we can spend more time on those issues that are genuinly important to Ubuntu. It is not a general rule to send everything to KDE that is not a packaging bug, but everything that does not have enough impact to be worth being persued by Ubuntu _as well_ as KDE.
This enables us to get the big issues resolved more quickly and also find them more easily (for core KDE components we can now mostly turn around bugs in < 48 hours).

In a perfect world we would not have to do that, but in the current situation it is the best we can do because the problem is of much greater complexity than is noticable at first sight.

[1] https://wiki.ubuntu.com/Bugs/HowToTriage