DrKonqi improvement idea

[henry miller]

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.sams at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120311/0b4772eb/attachment.htm>