at guadec, some people took a look over my shoulder to see me triaging (and Don told me about the correct pronounciation). of course the bugsquad sometimes teaches triaging to interested newbies in #bugs, but it was even more fun to explain stuff “in person” to muelli sitting next to me for example, or to discuss tips and tricks with other squadders (as long as claudio does not eat my cookies in the meantime, but of course he would never do). and people asked me to blog about it. now it’s october, and i’m late, but better than never:
a year ago i started to write a greasemonkey script that makes triaging faster in several points, and now i found time to clean up the code a bit (it’s still messy, but i never said that i wanna be a coder when i grow up ;-).
- add a “stacktrace” anchor link to the top of the page so you can directly jump to the signal handler call by clicking only once, and then compare two traces by quickly switching between the two browser tabs:
- add additional product- or distro-specific stock responses for some products that get a lot of reports, so it’s easier for reporters to install the right debug packages – for example, i also have “english, please!” or “this is not a support forum” stock responses for evolution bugs, because… i need them. sigh…:
- after clicking on the stock response, set keyboard focus to the “save changes” button to save the time you would need for scrolling otherwise
- reduce the width of the area containing the stock answer links. i have a big screen resolution and i like short ways
here you go for download (but be careful, it may eat your cat). feedback welcome, just send mail. (answers to possible questions: “i have only tested it in firefox, there will be problems with other browsers”, “no, the stacktrace anchor link cannot go upstream due to technical reasons”, “no, we don’t want individual answers for every single module and i don’t think it’s the way to go, it’s been just my personal workaround for some special cases and i thought it could be interesting for others too”.) thanks to nazgul for improvements and comments.
additionally, i have to say that having a laptop made triaging significantly faster for me too, because switching between keyboard and mouse on a desktop computer takes so much longer than using a touchpad and the keyboard which has only a few inches in-between them.
and i use keywords in firefox: you can open http://bugzilla.gnome.org/show_bug.cgi?id=100000 by entering “bug 100000” into the address bar, you only need a bookmark with the keyword “bug” and the address “http://bugzilla.gnome.org/show_bug.cgi?id=%s”. you can add keyword “q” to quickly get to the query page. and so on…
for the last months, the bugsquad started to add the STACKTRACE keyword to crasher reports with pretty perfect traces. useful evolution and nautilus reports should more or less be completely marked with that keyword now, so that hackers and contributors can find and fix crashers more easily. the keyword is especially useful for modules with a large income of reports and few developers/manpower, combining the querying with the latest version number. perhaps there’s some people around interested in marking good gtk+ crasher reports, and some other folks in fixing them?
i’ve added a few more resolved bugs to the auto-reject list so we get less dup reports. we still miss some information to track changes with regard to the number of rejected reports, so now that we reject reports from 2.16 distributions, i saved a copy of the auto-reject list to compare the numbers in a month, to find out which crashers don’t exist in >=2.18 anymore. easy one.
it’s amazing to see that we have a lot of bugsquadders currently (tom, susana, pedro, nazgul, bruno, diego, philip, muelli, cosimo, wolki and those that i’ve forgotten). i still wonder how we manage to create interest in this unpleasant repetitive gruntwork triaging work, but currently it looks like we’re successful in that. perhaps it’s time for me to look out for new challenges (and finish my studies to get a job). :-)