DrKonqi improvement idea

Niko Sams niko.sams at gmail.com
Sun Mar 11 17:08:28 GMT 2012


Am 11.03.2012 17:34 schrieb "Steven Sroka" <sroka.steven at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120311/1a34f8ab/attachment.htm>


More information about the kde-core-devel mailing list