Re: DrKonqi improvement idea
Niko Sams wrote: 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. -- Best Regards, Teemu Rytilahti
Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 22:20, Teemu Rytilahti t...@iki.fi wrote: Niko Sams wrote: 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. not yet, but I've seen it's perl :( and apperently integrated into bugzilla (just reading the project description) Niko
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: DrKonqi improvement idea
Quoting Niko Sams niko.s...@gmail.com: On Mon, Mar 12, 2012 at 17:32, Thomas Zander zan...@kde.org wrote: 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.. Well, we have to see how fast a duplicate search can be done. Maybe there could be a quick search that provides a immediate solution (if available) and a better slower background search. Good idea! -- Thomas Zander
Re: DrKonqi improvement idea
On Tuesday 13 March 2012 10:30:59 Thomas Zander wrote: 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. 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 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. 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
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: DrKonqi improvement idea
Don't forget security and privacy. The last n keys would be a bad thing to have if the user just entered a password. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Thomas Zander zan...@kde.org wrote: Quoting Niko Sams niko.s...@gmail.com: 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
Re: DrKonqi improvement idea
On Tue, Mar 13, 2012 at 12:27, Thomas Zander zan...@kde.org wrote: 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. I just found this, seems promising: https://fedorahosted.org/btparser/ Niko
Re: DrKonqi improvement idea
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.
Re: DrKonqi improvement idea
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,
Re: DrKonqi improvement idea
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. 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
Re: DrKonqi improvement idea
Milian Wolff wrote: 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
Re: DrKonqi improvement idea
On Mon, March 12, 2012 10:36 am, Thomas Zander wrote: 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
Re: DrKonqi improvement idea
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... Niko
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.
Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 09:54, Milian Wolff m...@milianw.de wrote: 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?! yeah, those people commenting after every release that the bug is 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
Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 01:14, Teemu Rytilahti t...@iki.fi wrote: 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. Interesting. But no system provides a solution I think. 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
Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 17:32, Thomas Zander zan...@kde.org wrote: 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.. Well, we have to see how fast a duplicate search can be done. Maybe there could be a quick search that provides a immediate solution (if available) and a better slower background search. Niko
Re: DrKonqi improvement idea
On Mon, Mar 12, 2012 at 11:36, Thomas Zander zan...@kde.org wrote: 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. That would provide useful information? I guess it depends on the 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
Re: DrKonqi improvement idea
Søndag den 11. marts 2012 11:26:53 skrev Niko Sams: 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 +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
Re: DrKonqi improvement idea
On 2012-03-11, at 10:21 AM, Milian Wolff wrote: On Sunday 11 March 2012 11:26:53 Niko Sams 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. 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. 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? Just for the ability to offer the user explicit feedback on his crash this project would be very appreciated though! bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: DrKonqi improvement idea
Am 11.03.2012 17:34 schrieb Steven Sroka sroka.ste...@gmail.com: On 2012-03-11, at 10:21 AM, Milian Wolff wrote: On Sunday 11 March 2012 11:26:53 Niko Sams 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. 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. 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. 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
Re: DrKonqi improvement idea
On Mar 11, 2012, at 3:26 AM, Niko Sams 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 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.
Re: DrKonqi improvement idea
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.s...@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
