Hello, more discussion about how to handle bugs are welcome, I
able to get in to the earlier thread, so I thought I should
> In short: DrKonqi shouldn't create bugs directly but talk to
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
(Socorro, shown in here , Microsoft  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
providing the binaries directly, which basically means that
they can do all
kinds of niceties out there too. See  for an example from
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
> - lists all reported crashes with intelligent filtering
I think DrKonqi already can get information whether there's
already with the same backtrace, or at least that information
for DrKonqi-reported bugs. One thing to consider there would
Traceparser (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
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
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
> that hits this crash)
> - comments can be added by users and developers (to ask how
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
> gets the possibility to
> subscribe to updates for this crash to get an email when a
> for his crash was entered
> by the developers
I don't like the idea of having a separate place for comments
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:  .
Anyway, the idea is good nevertheless.
> - sending a crash would not only help developers fixing that
> 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
be easily given to user in a "this bug is fixed in version x"
> What software could crashes.kde.org run? I'm not sure, maybe
> 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
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
whether that's worth it.
- When getting duplicate backtraces from users the bug entry
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"
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
The workflow could be something like this:
1. User encounters a crash and is asked whether to send a
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
4. If no complete matches available, ask user for more
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.