Good ideas, if anyone actually implements it. A couple of comments. Most users are not programmers - they will not know how to recogize similear backtraces are the same root cause. Worse I know of many cases where I - a programmer - was wrong.
The more automated detection we can do the better. In fact many random crashes have been traced down to the same root cause, so we really need the ability to check the user's config in a distribution specific way. If some misconfiguration is found we can ignore the backtrace. Keep privacy in mind as well. Since I'm not offering to do the painting I'll step away from the bikeshed now. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Niko Sams <niko.s...@gmail.com> wrote: Hi, I'd like to talk about an idea on how DrKonqi (which is a really useful thing btw) could be further improved. In short: DrKonqi shouldn't create bugs directly but talk to a "layer" between. DrKonqi -> crashes.kde.org -> bugs.kde.org crashes.kde.org is a new web application - a bit similar to bugzilla: - lists all reported crashes with intelligent filtering duplicates - developers can set duplicates - developers can link a crash to a bug (or create automatically a bug for a crash) - developers can enter a solution (that will be presented to the user that hits this crash) eg.: - "update to version x.y" - "temporary workaround: don't click button x" - "you missconfigured x, see http://y.com how to fix" - "the developers are aware of this issue but have not yet fixed it, see http://bugs.kde.org/... for details" - "the bug is fixed but an update has not yet been released. Update to version x.y once it released." - comments can be added by users and developers (to ask how to reproduce etc) For the end user there could be the following scenarios: - user posts the crash, crashes.kde.org finds a duplicate crash in it's database and will tell the user on how to proceed (see possible solutions above) - user posts the crash, crashes.kde.org can't find an exact duplicate and will show the user all possible duplicates - user posts the crash, crashes.kde.org doesn't find a duplicate. User gets the possibility to subscribe to updates for this crash to get an email when a solution for his crash was entered by the developers One big difference in implementation I would propose: DrKonqi makes a *single* POST to crashes.kde.org including all information and then just shows a WebView where the server side can do anything. That gives greater independence of the used KDE version and changes on the server side. Advantages over current solution: - bugs.kde.org isn't filled with duplicates - crashes.kde.org can be specialized on crashes - sending a crash would not only help developers fixing that bug but also help the user by showing a solution for his issue. What software could crashes.kde.org run? I'm not sure, maybe a bugzilla installation or something custom written. Or some other bugtracking software. So, what do you think? Niko