DrKonqi improvement idea
Niko Sams
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
Anders Lund
+1
I think communicating back to the user this way would be a great improvement
on user experience wrt bug handling. Sounds like the communication would be
much more/better structured than it is now.
Anders
Milian Wolff
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.
Just for the ability to offer the user explicit feedback on his crash this
project would be very appreciated though!
bye
--
Milian Wolff
ma...@milianw.de
http://milianw.de
Steven Sroka
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?
Niko Sams
I'd wouldn't do that - because it's not about bugs - it's about crashes. And instead of messing with the existing bugzilla I'd create something new.
>
> 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 :)
>
afaik windows sends only the errors (similar to what mozilla, gnome, ubuntu and others have).
My idea is more than that.
Niko
Gary Greene
Ubuntu has something similar iirc, same goes with the Linux Kernel project. (I recall hearing about it a couple years ago while at Google, so my memory could be a little fuzzy….)
--
Gary L. Greene, Jr.
===============================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
===============================================================
Please avoid sending me MS Office attachments.
Niko Sams
> Ubuntu has something similar iirc, same goes with the Linux Kernel project. (I recall hearing about it a couple years ago while at Google, so my memory could be a little fuzzy….)
>
They use the same system & database for bugs and crashes.
And I think they don't have a "solution" for the user.
Niko
henry miller
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.
Teemu Rytilahti
> 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
Milian Wolff
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...
Thomas Zander
> I'd like to talk about an idea on how DrKonqi
I'd say this is a great idea, mostly because it means a lot more can
be automated on lots of ends.
Naturally, the actual automation means research and development, which
means manpower. I didn't get from your email if you wanted to
volunteer for some of this work :)
Personally I'd go for a solution that also tries to register the last
20 keystrokes and 20 mouse clicks (qt global event listener) and if
and when a crash occurs that info can be send with the backtrace. So
even if there are no debug packages installed we get some info to do
data-mining on.
I'd also make your webpage (or site) be mostly dumb in the handling of
the data its being sent and then have a continues job on the machine
to actually process and handle these crash reports. So if we get
loads of requests in, we just store the data to be processed when
there is CPU available.
The reason is that I think we get much more useful information out of
this if we allow it to take more time than a webrequest would allow.
And also this will make the site much more responsive and painless.
It just scales better ;)
Either case, I'd think you want something custom written. Its not too
much work to do the basics and maybe we can steal some code that
compares backtraces and steal some ideas or code for on-disk
data-store of those backtraces.
Niko, I'm wondering if you can help out with realization of your
ideas, and if you have php or perl skills for instance.
I might find some time on my hands, and it sounds like a fun (and
needed) project so I could help out.
Cheers
--
Thomas Zander
Teemu Rytilahti
Hi again,
> 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.
Hmm, indeed, looks like I got carried out there, sorry about that. And yeah,
I agree with that there should be a way to give a clear message to the
users.
>> 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.
Keeping up the information in two separate databases wouldn't do good was my
ppint. But yeah, perhaps b.k.o should have some kind of separate field for
that kind of information, which would be then given out as needed.
> 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.
Yeah, agreed. In my opinion the comment section of bug entries could be even
more cleaned out, to just contain comments for example. Tens of "marked as
duplicate of" messages do not bring much more info while disturbing the real
comments. Mozilla uses an extension called inline history which shows
changes to bug statuses and also combine successive duplicate reports,
though the process is apparently so heavy the feature is not enabled for
users not logged in.
>> > 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.
Hmm, yup. The traceparser makes inlined backtraces to be not so verbose, but
doesn't remove the problem completely.
>> 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....
True, perhaps a separate field could be provided, and the comment closing
the bug could be used if none specified?
>> 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.
Yup, this comment was more about not having a need to create a separate
login, as I think that'll still be the barrier for getting reports. But
yeah, there are two sides in this.
>> - 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.
Well, basically if the reporting crashes will be much easier (esp. if no
login is needed) and there'll be loads of more reports, then issues might
surface on this front. This was mostly food for thought though.
>> - 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?!
Well, from what I've seen in bko people do ask whether the bug is still
reproducable, no? I see no reason why this information should pollute the
comments section, which should be in my opinion used for discussing the
specifics of the bug.
>> - 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?!
False positives, if that can happen. Also, this kind of information could be
used as a base to see from what kind of things bugs are triggered mostly?
But yeah, just thinking...
>> 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.
Yes.
> 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...
Indeed. Sounds good to me.
David Jarvie
> On Sunday 11 March 2012 11.26.53 Niko Sams wrote:
>> I'd like to talk about an idea on how DrKonqi
> []
>> What software could crashes.kde.org run? I'm not sure, maybe abugzilla
>> installation or somethingcustom written. Or some other bugtracking
>> software.
>
> I'd say this is a great idea, mostly because it means a lot more can
> be automated on lots of ends.
I like this idea too.
> I'd also make your webpage (or site) be mostly dumb in the handling of
> the data its being sent and then have a continues job on the machine
> to actually process and handle these crash reports. So if we get
> loads of requests in, we just store the data to be processed when
> there is CPU available.
> The reason is that I think we get much more useful information out of
> this if we allow it to take more time than a webrequest would allow.
> And also this will make the site much more responsive and painless.
> It just scales better ;)
There would be an advantage in giving instant feedback to the user if
possible, but if that turns out to be impractical, Thomas's suggestion of
using background processing on the server could be sensible.
I think Niko's proposal points to a deficiency in the current bug
reporting system, in that the current system doesn't provide a facility to
present the user with a quick summary of actions to take to resolve/work
around the bug. True, it does have the 'version fixed in' field for bugs
which are fixed, but there's nowhere that the developer can enter
workarounds etc. without them being lost in the bug discussion.
I'd suggest an extra text field called 'User action summary' at the top of
the bug report, under 'version fixed in'. Its purpose would be to give a
brief summary of how to avoid the bug (upgrade to version x.y.z / any
workarounds / etc.) or what is required from users to investigate it (e.g.
a summary of information needed). Reference could be made in the summary
to individual comments in the bug report. The user action summary should
only be editable by the assignee, to prevent users taking it upon
themselves to enter mistaken information.
This field could serve two purposes:
1) It would enable users to see at a glance what the status of the bug is,
even in a bug report containing long winded discussion or lots of
duplicate reports.
2) It could be used when crash reporting, to provide the user-intelligible
feedback which Niko is proposing. In this case, of course, there would
need to be a link between any crashes.kde.org and bugs.kde.org.
--
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm
Thomas Zander
> There would be an advantage in giving instant feedback to the user if
> possible, but if that turns out to be impractical, Thomas's suggestion of
> using background processing on the server could be sensible.
I was thinking about this a bit longer today and we[1] might do something
smart like letting the webapp generate a url thats unique for this person , or
the report and that url is his status page that will then get updated when
something new happens. A plasma app can use polling at regular intervals to
then show the user how his report progresses, including links to suggestions
like "fixed in ver xyz" or workarounds like; "don't use files with å or é in
them.".
1) saying 'we' is typically a bad thing if what you mean is "someone that is
not me" so lets be clear that I would love to do it, if time permits. Which
probably means soon, but not just yet.
--
Thomas Zander
Niko Sams
> 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.
But there is still room for improvement...
Niko
Martin Gräßlin
https://bugs.kde.org/report.cgi?x_axis_field=resolution&y_axis_field=&z_axis_field=&query_format=report-
table&short_desc_type=allwordssubstr&short_desc=&product=kwin&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=NEEDSINFO&bug_status=VERIFIED&bug_status=CLOSED&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&bug_severity=crash&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&emailtype3=substring&email3=&chfield=[Bug+creation]&chfieldvalue=&chfieldfrom=2011-01-01&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=&format=table&action=wrap
That's the stats for all crash reports reported against kwin since 01/01/2011
and now. It illustrates nicely one of the major problems of DrKonqui: you can
report the duplicates.
Of course KWin is the worst case scenario for measuring DrKonqui as we have
all those nice driver bugs ;-)
Cheers
Martin
Niko Sams
Well then KWin would profit a lot! And finding duplicates should be
done server side,
so it can be improved without having to wait for DrKonqi getting updated.
Niko
Martin Gräßlin
started I will support it, just to get to the point where we can tell users:
click foo than bar to disable baz and the crash is gone :-)
Cheers
Martin
Niko Sams
> On Monday 12 March 2012 02:14:00 Teemu Rytilahti wrote:
>> - 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?!
still not (magically) fixed :D
>> - 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?!
I would store all crashes, also duplicates
- maybe it's a false positive (that's what Teemu is talking about I think)
- it's an important fact to see how common a crash is
Niko
Niko Sams
> 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.
Socorro looks very powerful - but they need to process much more
crashes.
>> - 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.
Sounds good. One place is enough and fragmentation would be bad.
> - If there would be a separate crash-site, could it be worth
> to allow crash
> reports without login?
Maybe. But I would say we need the email address of the user to contact
him back.
> - Data sanitation? Ubuntu doesn't reveal the crash reports per
> default as
> they might contain something which shouldn't be public.
Right. But that sounds like manual work.
But currently DrKonqi also just posts the backtrace.
Niko
Niko Sams
> On Monday 12 March 2012 16.20.00 David Jarvie wrote:
>> There would be an advantage in giving instant feedback to the user if
>> possible, but if that turns out to be impractical, Thomas's suggestion of
>> using background processing on the server could be sensible.
>
> I was thinking about this a bit longer today and we[1] might do something
> smart like letting the webapp generate a url thats unique for this person , or
> the report and that url is his status page that will then get updated when
> something new happens. A plasma app can use polling at regular intervals to
> then show the user how his report progresses, including links to suggestions
> like "fixed in ver xyz" or workarounds like; "don't use files with å or é in
> them.".
be a quick search that provides a immediate solution (if available)
and a better & slower
background search.
Niko
Niko Sams
> On Sunday 11 March 2012 11.26.53 Niko Sams wrote:
>>
>> I'd like to talk about an idea on how DrKonqi
>
> []
>>
>> What software could crashes.kde.org run? I'm not sure, maybe abugzilla
>> installation or somethingcustom written. Or some other bugtracking
>> software.
>
>
> I'd say this is a great idea, mostly because it means a lot more can be
> automated on lots of ends.
> Naturally, the actual automation means research and development, which means
> manpower. I didn't get from your email if you wanted to volunteer for some
> of this work :)
>
> Personally I'd go for a solution that also tries to register the last 20
> keystrokes and 20 mouse clicks (qt global event listener) and if and when a
> crash occurs that info can be send with the backtrace. So even if there are
> no debug packages installed we get some info to do data-mining on.
application and bug.
> Either case, I'd think you want something custom written. Its not too much
> work to do the basics and maybe we can steal some code that compares
> backtraces and steal some ideas or code for on-disk data-store of those
> backtraces.
+1
The existing solutions are very complex and have lots of features. And
they solve different
use cases.
> Niko, I'm wondering if you can help out with realization of your ideas, and
> if you have php or perl skills for instance.
> I might find some time on my hands, and it sounds like a fun (and needed)
> project so I could help out.
I would have php skills, but I don't have that much spare time.
But with the positive feedback so far I think I will start with something.
Niko
Rolf Eike Beer
For me as a developer it would be useful e.g. if it would search for
duplicates before requesting the credentials. So I could decide that it's not
worth the effort to save them on some other host and search for dupes by hand
@home where I actually have the credentials at hand.
Eike
Teemu Rytilahti
> Interesting. But no system provides a "solution" I think.
> Socorro looks very powerful - but they need to process much more
> crashes.
Actually at least Microsoft does, not sure about the others. Not sure how
much is it used though, but the system has a capability to give an url where
to get more information and instructions, or even provide a link to a new
binary where the problem is fixed.
>> - If there would be a separate crash-site, could it be worth
>> to allow crash
>> reports without login?
> Maybe. But I would say we need the email address of the user to contact
> him back.
Yup, depends really on how much can be mined if there'd be a huge load of
backtraces. Nevertheless, from user point of view asking an email address
wouldn't be as bad as having to register to a separate site before
getting/submitting the information.
>> - Data sanitation? Ubuntu doesn't reveal the crash reports per
>> default as
>> they might contain something which shouldn't be public.
> Right. But that sounds like manual work.
> But currently DrKonqi also just posts the backtrace.
True, and this really depends what kind of information is being gathered.
One thing interesting which is a bit related is that one possibility would
be to gather other information from the system (Perhaps even per app-basis?
Automatically getting information about hardware & drivers for kwin bugs, as
an example). Same applied to other apps might cause some need to sanitize
and/or let users to choose what to send.
Teemu Rytilahti
> yeah, those people commenting after every release that the bug is
> still not (magically) fixed :D
One thing could be that the problem is caused by some other component in the
system. Or perhaps it's just the human nature doing its tricks there?
Nevertheless, if there's a need for confirming bugs against newer versions,
those reports shouldn't spam the comments section.
>> 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?!
> I would store all crashes, also duplicates
> - maybe it's a false positive (that's what Teemu is talking about I think)
> - it's an important fact to see how common a crash is
Exactly.
Teemu Rytilahti
>> Personally I'd go for a solution that also tries to register the last 20
>> keystrokes and 20 mouse clicks (qt global event listener) and if and when
>> a crash occurs that info can be send with the backtrace. So even if
>> there are no debug packages installed we get some info to do data-mining
>> on.
> That would provide useful information? I guess it depends on the
> application and bug.
In some cases yes, though not sure about how the probable privacy issues
could be handled nicely there in a way to not make people to avoid using it.
Not sure how useful it'd be for crashes, and sorry for hijacking the topic
for a bit again, in some cases a screenshot showing the problem would be
nice. Perhaps the report dialog could allow one to take a screenshot and
annotate it someway, just to make it clearer for triagers and developers
what's the intention :-)
>> Either case, I'd think you want something custom written. Its not too
>> much work to do the basics and maybe we can steal some code that compares
>> backtraces and steal some ideas or code for on-disk data-store of those
>> backtraces.
> +1
> The existing solutions are very complex and have lots of features. And
> they solve different
> use cases.
Have you already looked into traceparser (or any other similar system) to
see how it does the tricks? Just wondering if code from there could be
reused.
Niko Sams
bugzilla (just reading the project
description)
Niko
Myriam Schweingruber
On Mon, Mar 12, 2012 at 19:34, Martin Gräßlin <mgrae...@kde.org> wrote:
Worst case I don't know, if you apply the report to other large
projects you will get similar figures, see for example for Amarok:
http://bit.ly/wa6m4i
But then, we are all in the same boat with duplicates :)
Just my 2 ct: I don't think the user is able to actually judge if a
report is a duplicate one, so handling this on the server side would
be really a great idea, unless somebody (aka many) have time to triage
this on a daily basis. I agree on at least one point: duplicates
should not be reported without prior triage.
Regards, Myriam.
--
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)
Ben Cooksley
Whilst I have not evaluated it's compatibility with Bugzilla 4.2, I do
not suppose anyone has looked at
https://launchpad.net/bugzilla-traceparser ?
Regards,
Ben
Boudewijn Rempt
That looks very interesting and user-friendly to me.
Boudewijn
(who still has nightmares from having implemented breakpad and
socorro at a $DAYJOB).
Niko Sams
make sense to have even with crashes.kde.org.
Niko
Thomas Zander
> Whilst I have not evaluated it's compatibility with Bugzilla 4.2, I do
> not suppose anyone has looked at
> https://launchpad.net/bugzilla-traceparser ?
The traceparser might be a good-enough solution for finding duplicates
and helping the reading of backtraces, yes.
This thread is a bit more about solving the inital problem in a
different way since the actual usage of bugzilla for processing
backtraces is something that we probably want to sidestep in the first
place. Here is why;
* users that get a crash have to have a bugzilla account already if
they want to give it to us.
This is a problem because developers don't get a good insight of how
often things crash due to this higher level of contribution. Yes,
reporting a backtrace makes the user a contributor!
* users that get a crash are asked to themselves figure out if the
trace is a duplicate and are offered the option to add a cc instead of
a new report.
This is a problem because users are not capable of doing this and it
feels less-then-helpful to just cc yourself on a bugreport, which
means a lot of people just choose the safe route of creating a new
report.
* bugzilla holds backtraces as plain text in comments. Often mixed
with user-typed text.
This is a problem because it makes parsing and generating statistics
and automatic re-assignment near impossible. Consider how many ark
and konq bugs there are that are actually a crash inside of a random
kpart...
* bugzilla is meant to be for developers, users find it provides an
overkill of info and getting simple "disable feature X to stop the
crashing" is just impossible to communicate with the user right now.
* reporting to bugzilla means we have exactly one place where
*everything* kde based goes. A monolithic database shared by hudreds
of projects with 15 years of history.
This one is thinking ahead, thinking about the future handling of
project tasks and bugs and attacking the general dissatisfaction with
mozillas bugzilla tool (which I won't address here).
This database usage is a problem because it means the data is
unavailable for innovative (read; not yet invented) usage in
project-specific task-handling. Its also a problem for groups or
indivuduals that are geographically too far from bugs.kde.org to have
nice response times.
Ideally the improvement idea that I see forming in this thread makes
people stop reporting all backtraces to bugzilla but instead go to a
component that solves all those issues and one that distills the
inflow of traces into a limited number of issues. Those limited
number of issues can then be made into bugzilla tasks which are
handled as normal.
So, I'm interested (and active) in solving this in a way that is only
a little related to bugzilla and get free from the thinking imposed by
bugzilla.
--
Thomas Zander
Thomas Zander
Thomas Zander
> On Mon, Mar 12, 2012 at 11:36, Thomas Zander <zan...@kde.org> wrote:
>> I'd say this is a great idea, mostly because it means a lot more can be
>> automated on lots of ends.
>> Naturally, the actual automation means research and development, which means
>> manpower. I didn't get from your email if you wanted to volunteer for some
>> of this work :)
>>
>> Personally I'd go for a solution that also tries to register the last 20
>> keystrokes and 20 mouse clicks (qt global event listener) and if and when a
>> crash occurs that info can be send with the backtrace. So even if there are
>> no debug packages installed we get some info to do data-mining on.
>
> That would provide useful information? I guess it depends on the
> application and bug.
In my experience its useful in many cases. If your application is
complicated then just having a backtrace, even with linenumbers, may
not allow you to reproduce the crash. You need some extra info to know
what the user did just before it crashed.
Asking the user is not the best solution; I've seen many backtraces
with a comment from the user stating they were typing some text, while
the backtrace showed they were printing. Its hard to be a debugger
when your work just got lost...
A better solution would be that we know which buttons were clicked and
that the user pressed the tab button or the ctrl-w buttons etc.
So, I'd say this can be very useful to get the whole picture of the
moment the crash happened :)
And this also means that duplicates are good, the backtrace may be the
same but we still add useful info to the issue.
>> Either case, I'd think you want something custom written. Its not too much
>> work to do the basics and maybe we can steal some code that compares
>> backtraces and steal some ideas or code for on-disk data-store of those
>> backtraces.
> +1
> The existing solutions are very complex and have lots of features. And
> they solve different
> use cases.
Hmm, its indeed not easy to find something fitting. Looking at the
code of one of the links found in this thread, I notice its written in
perl. While I understand the urge to do that, I'm not convinced that
there is enough perl knowledge in KDE to make sysadmin happy if we
just imported their systems. How hard can it be to parse a backtrace
anyway? ;-)
Anyway, the actual core parsing and matching will probably be
something that can be improved over time. Possibly with the help of
other open source code.
--
Thomas Zander
Christoph Feck
> Quoting Ben Cooksley <bcoo...@kde.org>:
> > Whilst I have not evaluated it's compatibility with Bugzilla 4.2,
> > I do not suppose anyone has looked at
> > https://launchpad.net/bugzilla-traceparser ?
>
> The traceparser might be a good-enough solution for finding
> duplicates and helping the reading of backtraces, yes.
>
> This thread is a bit more about solving the inital problem in a
> different way since the actual usage of bugzilla for processing
> backtraces is something that we probably want to sidestep in the
> first place. Here is why;
>
> * users that get a crash have to have a bugzilla account already if
> they want to give it to us.
> This is a problem because developers don't get a good insight of
> how often things crash due to this higher level of contribution.
> Yes, reporting a backtrace makes the user a contributor!
>
> * users that get a crash are asked to themselves figure out if the
> trace is a duplicate and are offered the option to add a cc instead
> of a new report.
> This is a problem because users are not capable of doing this and
> it feels less-then-helpful to just cc yourself on a bugreport,
> which means a lot of people just choose the safe route of creating
> a new report.
I have long been interested why users keep reporting duplicates.
Instead of guessing, let's just ask them in a nice way. I added
https://bugs.kde.org/show_bug.cgi?id=295919#c1 to a frequently
reported bug, and maybe we can this way get some insights. Unless
someone objects, this survey could be sent to reporters of frequently
reported crashes (maybe not in the comment, but per reply).
My guess is that DrKonqi simply does not make it clear that the bug
has already been reported several times.
Bugzilla has a long tradition of being a tool that annoys users,
developers, as well as bug triagers. Anything that improves the
situation is welcomed :)
Christoph Feck (kdepepo)
KDE Quality Team
Martin Gräßlin
to also add a keyword or flag to the bugs so that we can easily search for
those where we asked the users?
Maybe a flag "quality-survey-asked" for when you request and "quality-survey-
provided" when the user provided the feedback.
Cheers
Martin
Myriam Schweingruber
> On Tuesday 13 March 2012 17:00:29 Christoph Feck wrote:
>>
>> I have long been interested why users keep reporting duplicates.
>> Instead of guessing, let's just ask them in a nice way. I added
>> https://bugs.kde.org/show_bug.cgi?id=295919#c1 to a frequently
>> reported bug, and maybe we can this way get some insights. Unless
>> someone objects, this survey could be sent to reporters of frequently
>> reported crashes (maybe not in the comment, but per reply).
>>
>> My guess is that DrKonqi simply does not make it clear that the bug
>> has already been reported several times.
I am pretty sure it doesn't, as the list of the similar bugs appears
at the bottom of the backtrace, a place nobody is going to look for
it. And once it is reported, the user isn't likely to see it either as
s/he will not open the bug report and check what is written at the
bottom of the backtrace.
Dr. Konqi should clearly display the possible duplicates to the user,
on top of the backtrace or by a message telling that possible
duplicates were found. The message could then continue like this: "if
you are unsure whether your report is a duplicate or not, stop here,
if you are an experience users who knows how to read backtraces and
find duplicates you can continue." (in a more appropriate wording of
course).
Regards, Myriam
henry miller
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
< br />>> Either case, I'd think you want something custom written. Its not too much
Niko Sams
> Hmm, its indeed not easy to find something fitting. Looking at the code of
> one of the links found in this thread, I notice its written in perl. While I
> understand the urge to do that, I'm not convinced that there is enough perl
> knowledge in KDE to make sysadmin happy if we just imported their systems.
> How hard can it be to parse a backtrace anyway? ;-)
> Anyway, the actual core parsing and matching will probably be something that
> can be improved over time. Possibly with the help of other open source code.
https://fedorahosted.org/btparser/
Niko