Auto rejecting ‘bad’ stack traces

As of yesterday I’ve made it possible to reject very specific ‘bad’ stack traces. This has been used by Karsten Bräckelmann to auto-reject Evolution crashers with a unusable stack trace. Evolution gets 50+ of such bugreports per day and that was killing the Bugsquad.
FYI: In total, the auto-rejecter has rejected close to 700 bugreports (in about a weeks time). I’d expect it to reject an additional 1000 bugreports next week.

Karsten Bräckelmann is currently the only one adding stack traces to the auto-rejecter. This because I want to be really careful not to accidentally reject valid bugreports. In future I’d like to open this up to people assigned within Bugzilla as developers of a project. Such people would only be able to auto-reject bugreports for their project only.

To be able to reject the unusable stack traces, the server (‘Bug-Buddy’ from a user perspective) can now mail the user with an explanation. This explanation is added by the Bugsquad and differs per specific stack trace. For the unusable Evolution stack traces the explanation tries to guide the user into installing debug packages. After the user has installed these this, the stack trace will differ and it will not be auto-rejected anymore. The mail also contains a copy of the entire bugreport that was rejected/ignored.

Such an explanation can be used on any auto-rejected (or ignored) stack trace. So in future we could maybe tell the user this bug was fixed in a newer version. Currently the explanation has to go via email, but I hope to be able to return this information to Bug-Buddy directly (although probably in English only). Wouldn’t it be great if the user would know right away to bug his distribution for an update? Maybe in some distant future Bug-Buddy will have a ‘Install newer version’ button 🙂

Fer (Bug-Buddy maintainer) is also looking at/working on (the long planned) debug server. This thanks to Airbag; a Google project to create a crash reporting system. If Bug-Buddy detects that gdb wasn’t installed (or no debug symbols), it could use airbag to send a mini coredump to a debug server. The debug server would need debug packages for a few well known distributions. Using the minidump and the debug packages it could create a good stack trace. Although some bugs a distribution specific (usually because of their customizations), having a debug server setup with even just two distributions would really help developers fix crashers faster.

Finally, I’d like to welcome Jan Arne Petersen (178 closed bugs), and Susana (92 closed bugs) to the Bugsquad. Hopefully I did not forget anyone… For anyone wanting to join, usually is best to hang around in the evening (CET/Europe time — UTC +1) at irc.gnome.org, channel #bugs (use an IRC client like xchat). Just ask a question and someone should respond within an a few seconds (can take a lot longer.. even 1 hour.. means nobody is currently behind his/hers pc).