DrKonqi improvement idea

[Teemu Rytilahti]

Niko Sams wrote:

> Hi,

Hello, more discussion about how to handle bugs are welcome, I 
hope. Wasn't 
able to get in to the earlier thread, so I thought I should 
post something 
here.

> In short: DrKonqi shouldn't create bugs directly but talk to 
a "layer"
> between.

This really depends on how it'd be used, but perhaps yeah, 
this might be a 
good idea indeed. This is something I encountered while 
working on a course 
paper earlier this semester. Similar systems are up there for 
Mozilla 
(Socorro[1], shown in here [2], Microsoft [3] and Ubuntu too. 
I bet that 
LibreOffice might have something similar too, but haven't 
looked into that.

One thing which makes all of this easier for them though is 
that they're 
providing the binaries directly, which basically means that 
they can do all 
kinds of niceties out there too. See [4] for an example from 
Ubuntu-land.

This doesn't though mean that we couldn't do similar in KDE 
too, and it 
probably would be a good idea.

> crashes.kde.org is a new web application - a bit similar to 
bugzilla:
> - lists all reported crashes with intelligent filtering 
duplicates

I think DrKonqi already can get information whether there's 
duplicates 
already with the same backtrace, or at least that information 
is available 
for DrKonqi-reported bugs. One thing to consider there would 
be whether 
Traceparser[5] (used in Gnome's bugzilla, too) could be used 
there if needed 
to get numerical scores for backtraces.

> - developers can set duplicates

Not sure whether this would work, more manual work all around 
while the 
triagers are already overloaded afaik. As much as possible 
should be done 
automatically. Though I think the duplicate detector in 
DrKonqi works quite 
well nowadays and doesn't allow even submit duplicate crashes.

> - developers can link a crash to a bug (or create 
automatically a bug
> for a crash)

This is how it works for Mozilla at least if I haven't 
misunderstand their 
processes. A good idea. This can be used later on to redirect 
the user to 
the bug like you mention later on.

> - developers can enter a solution (that will be presented to 
the user
> that hits this crash)
[snip]
> - comments can be added by users and developers (to ask how 
to reproduce
> etc)

How about just having the crashes linked to b.k.o entry? So 
that the crash 
database would just for crashes, no comments etc.

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

I don't like the idea of having a separate place for comments 
and/or 
solutions, but that's just me. In my opinion the commenting 
could happen in 
a valid b.k.o entry as needed.
 
> Advantages over current solution:
> - bugs.kde.org isn't filled with duplicates

Not sure if this is an issue anymore regarding to crashes. 
Couldn't find the 
blog entry related to this quickly, but here's a reviewboard 
entry: [6] . 
Anyway, the idea is good nevertheless.

> - sending a crash would not only help developers fixing that 
bug but
> also help the user by showing
>   a solution for his issue.

This would be a great plus indeed, though would need 
adaptation on processes 
depending on how specific solutions should be shown to the 
user. If fixed-in 
tags or similar are set to bugs when they're fixed, that 
information could 
be easily given to user in a "this bug is fixed in version x" 
sense.

> 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?

Some things to consider:
- If there would be a separate crash-site, could it be worth 
to allow crash 
reports without login?
- Data sanitation? Ubuntu doesn't reveal the crash reports per 
default as 
they might contain something which shouldn't be public.
- It might be possible to use a separate Bugzilla instance 
just for this, 
but I'm not sure how well migrating bugs between instances do 
work or 
whether that's worth it.
- When getting duplicate backtraces from users the bug entry 
could be 
updated automatically with the version the crash happened, 
this would in my 
opinion be a plus in a sense that "can reproduce in version x" 
entries 
wouldn't flood the comment section. Anyway, this is something 
which could be 
generally available for all bugs...
- Is there a need to keep duplicate crashes in the database, 
maybe for false 
positives?

The workflow could be something like this:
1. User encounters a crash and is asked whether to send a 
report.
2. If yes, a backtrace is being send to the server.
3. If there's a complete match, just inform the user about it 
and give a 
link to a bug report / perhaps allow add a new comment to 
report?
4. If no complete matches available, ask user for more 
information what 
happened, just like Konqi does already.
5. Make an entry to the crash database.
6. Somehow a crash is being confirmed and moved to b.k.o.
7. Live happily ever after.

That's my 0.02e for the time being, I think. Sorry for the 
lengthy mail, but 
hope there's some food for thought in there.


[1] https://blog.mozilla.com/webdev/2010/05/19/socorro-
mozilla-crash-
reports/
[2] https://crash-stats.mozilla.com/products/Firefox
[3] 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.716&rep=rep1&type=pdf
[4] http://www.piware.de/2011/11/apport-1-90-client-side-
duplicate-checking/
[5] https://launchpad.net/bugzilla-traceparser
[6] https://git.reviewboard.kde.org/r/102921/

-- 
Best Regards,
Teemu Rytilahti