Quoting Ben Cooksley <bcooks...@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
