[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: DrKonqi improvement idea
From:       Steven Sroka <sroka.steven () gmail ! com>
Date:       2012-03-11 16:33:48
Message-ID: 949B3C6D-F837-4E45-B2E6-F5AF13B6642D () gmail ! com
[Download RAW message or body]


On 2012-03-11, at 10:21 AM, Milian Wolff wrote:

> 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 
> own.

It would take quite some effort. I would say building this into bugs.kde.org would be \
the better option since the less layers, the complex the bug tracker is.

Side note: Niko, what you are proposing is something that Windows Error Reporting has \
been doing for years, and it seems to have served Microsoft well :)

The problem is… do we have the resources to implement it *if* it is the best solution \
for us?



> 
> Just for the ability to offer the user explicit feedback on his crash this 
> project would be very appreciated though!
> 
> bye
> -- 
> Milian Wolff
> mail@milianw.de
> http://milianw.de


[prev in list] [next in list] [prev in thread] [next in thread]