DrKonqi improvement idea

Milian Wolff mail at milianw.de
Sun Mar 11 14:21:42 GMT 2012

On Sunday 11 March 2012 11:26:53 Niko Sams 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.

In short: I like the idea.

But I guess this needs someone to step up and actually write the required 
software. I doubt our dear sysadmins can spare the time and I also wonder 
whether it's worth to spent time on getting this quite custom functionality 
into an existing bugtracker software instead of writing the software on once 

Just for the ability to offer the user explicit feedback on his crash this 
project would be very appreciated though!

Milian Wolff
mail at milianw.de

More information about the kde-core-devel mailing list