DrKonqi improvement idea

[Thomas Zander]

Quoting Ben Cooksley <bcooksley at 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