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).

Handing the Sword of A Thousand Truths to Bugsquad

New developments in the story about stopping the hacker with absolutely no life

Currently the following is a pretty common picture if you look at the weekly-bug-summary:

Two bugsquad members closing more than 1000 bugs in 7 days

However, the Sword of A Thousand Truths has been found, and is about to be handed over to the Bugsquad:

Picture of the sword

And for everyone who wants some real details: I’ve created a way to have bug-buddy bugs ‘rejected’/’ignored’ using the stack trace. Something like this I’ve implemented before for the old Bug-Buddy interface. However, this one had to be created from scratch.

What it currently does:

  • Uses 5 functions of a stack trace
  • Optionally limited to a product, product version or GNOME version
  • To the user it will pretend the user created the original bug (the one with the many duplicates.. this because I cannot send a good error message to the current Bug-Buddy versions)
  • There is a nice interface for experienced bugsquad members to add/edit/remove the stack traces that are rejected/ignored.
  • Allowing developers to add stack traces to be rejected is on the todo list, but I need to make the UI better first
  • If a bug will have stack traces auto-rejected, Bugsquad will (manually) add a note pointing to this page (this page is still being edited).
  • The patch has been committed just recently.. obviously it lacks documentation + it could do a few things better, etc.

Technical details can be found here.
The patch that does this (have been changes since this) is here.

Finally, Karsten Bräckelmann and Andre Klapper: many many thanks for continuing to close so many bugs.