Jetpack which turned into a medium range missile

St 13 ledna 2010

While reading the story about b.m.o jetpack, I decided that the time has come to reveal to the wider world existence of the jetpack (originally a Greasemonkey script), which is being used by the Fedora BugZappers (aka voluntary bug triagers). Let me show you first how Red Hat Bugzilla looks without any additional tweaking (this is the look a Bug Zapper see, both normal user and a Red Hat employee have page quite different; click the thumbnail for the full-size screenshot). This is the top of the page (forgive momentarily indisposition of some parts of the layout, we are in the process of upgrading to bugzilla 3.4 and there are apparently some small issues with layout):

plain top of the bugzilla page without any changes

and this is the middle part of the page:

plain middle of the bugzilla page without any changes

When writing these scripts (first Greasemonkey and now Jetpack) I was not that much concerned about displaying the data about the bug (although there are some visual effects available as well, about which later), but making it more simple to change it as fast as possible. Therefore, the main bulk of my work was adding a lot of buttons everywhere which would add prefiled comments and change the state of the bug accordingly. Let me show you how the top of the page looks like:

top of the bugzilla page changed by the scripts

There are not that many changes in the top of the page. The most visible one is changed background of whole page. One problem I had when dealing with tens (or sometimes hundreds) of bugs a day was a need to be conscious of what kind of reporter I am speaking to. Of course, one should use different tone and expect different level of knowledge from reporter of bug for Fedora Rawhide (a development version of Fedora, very bleeding-edge, sometimes with a stress on the word “bleeding” ;)) and from another reporter who has an issue with Red Hat Enterprise Linux communicating with us through our main support system. Different colors for different products (this green is for Rawhide) give me right subconscious feeling of what I should expect and what I could require from the reporter. Another interesting change is a button “Def. Assignee” next to the “Assigned To” text box. When the jetpack is loaded on the startup of the browser, it also loads a JSON file with a lot of configuration both local to the Red Hat bugzilla instance and specific to the particular bug triager (it is possible to change via tiny link “BugZap config” URL from which the JSON file is downloaded, so everybody can make her own settings and even buttons specific to the particular component she deals with; one JSON file is used as default). One of the things which are in the JSON is an object like this (in reality it is much larger):

"defaultAssignee": [
      "regexp": "xorg-x11-(server.*|drv-vesa|drv-mga)",
      "addr": ""
      "regexp": "xorg-x11-drv-(nv|nouveau)",
      "addr": ""

and then I have in the script this function::

filterByRegexp = function(list, chosingMark) {
var chosenPair = [];
if (list.length > 0) {
  chosenPair = list.filter (
          function (pair) {
              return new RegExp(pair.regexp, "i").test(chosingMark);
if (chosenPair.length > 0) {
  return chosenPair[0].addr.trim();
} else {
  return "";

With this function I am then able to simply set default assignee of the bug with::

this.changeOwner(filterByRegexp(defAssigneeList, this.component).

I had created filterByRegexp construct just as a quick hack for picking the default assignee, but I disovered later that this is actually dictionary indexed by regular expression and that it is quite useful function to have. Let’s go to the middle of the page where I can explain the idea of generality of the script:

middle of the bugzilla page heavily changed by the scripts

The most visible change here are many additional buttons we have here. Interesting thing about them is that two lines of buttons, one above and one below the comment box (from “X logs” to “flashCrash” and from “NEEDINFO” to “Retest”) are actually generated based on the JSON file, so every user can have her set of buttons (surprisingly, not everybody needs /var/log/Xorg.0.log). The idea behind most of the business logic (so to say) pushed to configuration file was not only to make script configurable for individual users, but I hoped that I could make the script also independent of the quirks of the Red Hat bugzilla instance so that the same code could be used by other bugzillas. I am afraid I have failed in this respect, and there are many instances of redhatisms in my code. However, the basic infrastructure is there, so it should be possible to debug the script to be truly independent. The two buttons just below the “Additional comments” label are hard-wired to the script (although they can be switched on and off in the JSON file and they’re off per default). “Query for string” takes content of the clipboard and opens in the next tab a query for this text in the comments, summary, or content of attachments. I found this button to be a perfect tool for discovering duplicates. The second button “Send upstream” collects data from the bug (summary and text of all comments) and opens in the next tab entry page of the upstream bugzilla (currently tested only with MoFo bugzilla) and populates its fields with data collected from the Fedora bug. Of course, new upstream bug needs a lot of editing to be nice new bug, but it saves a lot of work, and it shows how Jetpack scripts are capable of a lot of very useful activity. The last thing shown on our image is that the comment 10 has a light yellow background. I found it quite useful to be able to easily recognize which comments on the bug are from the original reporter, and which are from developers or from random people commenting on the bug. For example, it happened to me couple of times, that somebody random commented that the bug has been fixed, and when I happily closed the bug as resolved, the real reporter came with venegance on me. By having yellow background (or rather by not-having it), I can clearly see how significant is any particular comment for the fate of the bug. As I said, I hope to make this script general enough to be used by other bug triagers in the similar situations. Yes, some features I have created in my script could be usefully pushed to the bugzilla itself, but I am quite certain that majority of the script is specific enough for the bug triagers work, that it doesn't make much sense to burden bugzilla itself with it. If you find that you are able to make my script work for you on another bugzilla, please, send me patches and I will try to accommodate my script to work for you.

Category: computer Tagged: bugTriage jetpack