DrKonqi improvement idea

[Milian Wolff]

On Monday 12 March 2012 02:14:00 Teemu Rytilahti wrote:
> 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.

While nice this is not required for Niko's proposal. Either the backtrace is 
automatically associated with a solution, or a developer later on associates 
it with a solution or a bug report. In the former case, the user gets direct 
feedback on what's going on. In the latter, he will at least get a concise 
email - at least that's what I have in mind (and I think Niko as well).

The big difference to our current solution is just that users get far less 
emails, like "bug XYZ marked as duplicate". Or mails for developer discussions 
in bug reports, something that most users won't understand anyways.

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

Hum how is this more work? Actually I cannot see how this can create more 
work, if at all only the same amount. On the contrary I think Niko's proposal 
can reduce the workload! The reason is that users should then - in theory - 
get a concise, short and readable instruction that should explain them how to 
fix their crash. "Update to version XYZ" for example.

Even in KDevelop, an app where our userbase should be somewhat proficient with 
the whole development process, we get tons of emails because people add their 
"+1 crashed for me as well" backtraces to some hideously old bug report. And 
why? Because they don't read the bug reports. Somewhere in the comments there 
might be a "fixed by commit xyz" message, but they simply don't care.

If now they would see a simple "this is fixed by version XYZ - please update", 
then it would help me personally quite much already.

Of course we can still improve the backtrace matching eventually, but this is 
unrelated to the proposal at hand here I think.

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

+1

either the crash is new -> new entry, or the crash is not yet fixed -> comment 
on b.k.o. 

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

yes, see above. solutions should be separated though - otherwise people won't 
find it. that's the crucial point here I think.

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

maybe not duplicates, but definitely about "+1 crashes for me as well" 
messages for long since fixed crashes.

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

or the developer takes the time to tell people he fixed the bug somewhere. 
seriously, that's not too much to ask of them....

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

maybe in the first step, but once they found an actual crash I really think 
they need to provide an email for asking for feedback and such.

> - Data sanitation? Ubuntu doesn't reveal the crash reports per
> default as
> they might contain something which shouldn't be public.

how is this related to this proposal? our current solution has the same 
problem and maybe/probably some kind of code in place to achieve that.

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

I don't get how this is valuable feedback. If I didn't fix a bug of course it 
will be reproducible in later versions?!

> - Is there a need to keep duplicate crashes in the database,
> maybe for false
> positives?

hu? I don't get this one. if it's a duplicate then by definition one doesn't 
need its information because it's already known?!

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

only if: bug is not fixed or current version is *higher* than the assumed 
fixed-in version.

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

8. developer fixes bug, associates a "solution" to the crash, user that 
reported the crash gets an email notification.

this is pretty crucial and the whole point of this proposal...

bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de