Niko Sams wrote: > Hi,
Hello, more discussion about how to handle bugs are welcome, I hope. Wasn't able to get in to the earlier thread, so I thought I should post something here. > In short: DrKonqi shouldn't create bugs directly but talk to a "layer" > between. This really depends on how it'd be used, but perhaps yeah, this might be a good idea indeed. This is something I encountered while working on a course paper earlier this semester. Similar systems are up there for Mozilla (Socorro[1], shown in here [2], Microsoft [3] and Ubuntu too. I bet that LibreOffice might have something similar too, but haven't looked into that. One thing which makes all of this easier for them though is that they're providing the binaries directly, which basically means that they can do all kinds of niceties out there too. See [4] for an example from Ubuntu-land. This doesn't though mean that we couldn't do similar in KDE too, and it probably would be a good idea. > crashes.kde.org is a new web application - a bit similar to bugzilla: > - lists all reported crashes with intelligent filtering duplicates I think DrKonqi already can get information whether there's duplicates already with the same backtrace, or at least that information is available for DrKonqi-reported bugs. One thing to consider there would be whether Traceparser[5] (used in Gnome's bugzilla, too) could be used there if needed to get numerical scores for backtraces. > - developers can set duplicates Not sure whether this would work, more manual work all around while the triagers are already overloaded afaik. As much as possible should be done automatically. Though I think the duplicate detector in DrKonqi works quite well nowadays and doesn't allow even submit duplicate crashes. > - developers can link a crash to a bug (or create automatically a bug > for a crash) This is how it works for Mozilla at least if I haven't misunderstand their processes. A good idea. This can be used later on to redirect the user to the bug like you mention later on. > - developers can enter a solution (that will be presented to the user > that hits this crash) [snip] > - comments can be added by users and developers (to ask how to reproduce > etc) How about just having the crashes linked to b.k.o entry? So that the crash database would just for crashes, no comments etc. > - user posts the crash, crashes.kde.org doesn't find a duplicate. User > gets the possibility to > subscribe to updates for this crash to get an email when a solution > for his crash was entered > by the developers I don't like the idea of having a separate place for comments and/or solutions, but that's just me. In my opinion the commenting could happen in a valid b.k.o entry as needed. > Advantages over current solution: > - bugs.kde.org isn't filled with duplicates Not sure if this is an issue anymore regarding to crashes. Couldn't find the blog entry related to this quickly, but here's a reviewboard entry: [6] . Anyway, the idea is good nevertheless. > - sending a crash would not only help developers fixing that bug but > also help the user by showing > a solution for his issue. This would be a great plus indeed, though would need adaptation on processes depending on how specific solutions should be shown to the user. If fixed-in tags or similar are set to bugs when they're fixed, that information could be easily given to user in a "this bug is fixed in version x" sense. > What software could crashes.kde.org run? I'm not sure, maybe a > bugzilla installation or something > custom written. Or some other bugtracking software. > > So, what do you think? Some things to consider: - If there would be a separate crash-site, could it be worth to allow crash reports without login? - Data sanitation? Ubuntu doesn't reveal the crash reports per default as they might contain something which shouldn't be public. - It might be possible to use a separate Bugzilla instance just for this, but I'm not sure how well migrating bugs between instances do work or whether that's worth it. - When getting duplicate backtraces from users the bug entry could be updated automatically with the version the crash happened, this would in my opinion be a plus in a sense that "can reproduce in version x" entries wouldn't flood the comment section. Anyway, this is something which could be generally available for all bugs... - Is there a need to keep duplicate crashes in the database, maybe for false positives? The workflow could be something like this: 1. User encounters a crash and is asked whether to send a report. 2. If yes, a backtrace is being send to the server. 3. If there's a complete match, just inform the user about it and give a link to a bug report / perhaps allow add a new comment to report? 4. If no complete matches available, ask user for more information what happened, just like Konqi does already. 5. Make an entry to the crash database. 6. Somehow a crash is being confirmed and moved to b.k.o. 7. Live happily ever after. That's my 0.02e for the time being, I think. Sorry for the lengthy mail, but hope there's some food for thought in there. [1] https://blog.mozilla.com/webdev/2010/05/19/socorro- mozilla-crash- reports/ [2] https://crash-stats.mozilla.com/products/Firefox [3] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.716&rep=rep1&type=pdf [4] http://www.piware.de/2011/11/apport-1-90-client-side- duplicate-checking/ [5] https://launchpad.net/bugzilla-traceparser [6] https://git.reviewboard.kde.org/r/102921/ -- Best Regards, Teemu Rytilahti