Re: Re: DrKonqi improvement idea
Hi all, On Mon, Mar 12, 2012 at 19:34, Martin Gräßlin mgraess...@kde.org wrote: On Monday 12 March 2012 19:26:27 Niko Sams wrote: On Sun, Mar 11, 2012 at 13:57, henry miller h...@millerfarm.com wrote: ... *cough* https://bugs.kde.org/report.cgi?x_axis_field=resolutiony_axis_field=z_axis_field=query_format=report- tableshort_desc_type=allwordssubstrshort_desc=product=kwinbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=NEEDSINFObug_status=VERIFIEDbug_status=CLOSEDlongdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_id=bug_id_type=anyexactvotes=votes_type=greaterthaneqbug_severity=crashemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=emailtype3=substringemail3=chfield=[Bug+creation]chfieldvalue=chfieldfrom=2011-01-01chfieldto=Nowj_top=ANDf1=noopo1=noopv1=format=tableaction=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 ;-) 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)
Re: Re: DrKonqi improvement idea
Hi all, 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
Re: Re: DrKonqi improvement idea
On Tue, 13 Mar 2012, Ben Cooksley wrote: Hi all, 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 ? That looks very interesting and user-friendly to me. Boudewijn (who still has nightmares from having implemented breakpad and socorro at a $DAYJOB).
Re: Re: DrKonqi improvement idea
On Tue, Mar 13, 2012 at 09:47, Ben Cooksley bcooks...@kde.org wrote: Hi all, 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 ? well, that's off topic for this thread. But still would probably make sense to have even with crashes.kde.org. Niko
Re: Re: DrKonqi improvement idea
Quoting Ben Cooksley bcooks...@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. * 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
Re: Re: DrKonqi improvement idea
On Tue, Mar 13, 2012 at 17:25, Martin Gräßlin mgraess...@kde.org wrote: 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 -- 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)
Re: Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 19:34, Martin Gräßlin mgraess...@kde.org wrote: On Monday 12 March 2012 19:26:27 Niko Sams wrote: On Sun, Mar 11, 2012 at 13:57, henry miller h...@millerfarm.com wrote: 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. DrKonqi already detects duplicates, which works pretty good usually. But there is still room for improvement... *cough* https://bugs.kde.org/report.cgi?x_axis_field=resolutiony_axis_field=z_axis_field=query_format=report- tableshort_desc_type=allwordssubstrshort_desc=product=kwinbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=RESOLVEDbug_status=NEEDSINFObug_status=VERIFIEDbug_status=CLOSEDlongdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_id=bug_id_type=anyexactvotes=votes_type=greaterthaneqbug_severity=crashemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=emailtype3=substringemail3=chfield=[Bug+creation]chfieldvalue=chfieldfrom=2011-01-01chfieldto=Nowj_top=ANDf1=noopo1=noopv1=format=tableaction=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 ;-) wow, you poor guy :D 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
Re: Re: Re: DrKonqi improvement idea
On Monday 12 March 2012 19:39:12 Niko Sams wrote: On Mon, Mar 12, 2012 at 19:34, Martin Gräßlin mgraess...@kde.org wrote: On Monday 12 March 2012 19:26:27 Niko Sams wrote: On Sun, Mar 11, 2012 at 13:57, henry miller h...@millerfarm.com wrote: 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. DrKonqi already detects duplicates, which works pretty good usually. But there is still room for improvement... *cough* https://bugs.kde.org/report.cgi?x_axis_field=resolutiony_axis_field=z_ax is_field=query_format=report- tableshort_desc_type=allwordssubstrshort_desc=product=kwinbug_status UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_sta tus=RESOLVEDbug_status=NEEDSINFObug_status=VERIFIEDbug_status=CLOSEDlo ngdesc_type=allwordssubstrlongdesc=bug_file_loc_type=allwordssubstrbug_ file_loc=keywords_type=allwordskeywords=bug_id=bug_id_type=anyexactvo tes=votes_type=greaterthaneqbug_severity=crashemailassigned_to1=1email type1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1em ailtype2=substringemail2=emailtype3=substringemail3=chfield=[Bug+creat ion]chfieldvalue=chfieldfrom 11-01-01chfieldto=Nowj_top=ANDf1=noop o1=noopv1=format=tableaction=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 ;-) wow, you poor guy :D Well then KWin would profit a lot! yes, indeed and I must say that I think your idea is great. If a project gets 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 And finding duplicates should be done server side, so it can be improved without having to wait for DrKonqi getting updated. Niko signature.asc Description: This is a digitally signed message part.
