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