summaryrefslogtreecommitdiffstats
path: root/_posts/jetpack-which-turned-into-a-medium-range-missile.rst
diff options
context:
space:
mode:
Diffstat (limited to '_posts/jetpack-which-turned-into-a-medium-range-missile.rst')
-rw-r--r--_posts/jetpack-which-turned-into-a-medium-range-missile.rst165
1 files changed, 165 insertions, 0 deletions
diff --git a/_posts/jetpack-which-turned-into-a-medium-range-missile.rst b/_posts/jetpack-which-turned-into-a-medium-range-missile.rst
new file mode 100644
index 0000000..fb031ae
--- /dev/null
+++ b/_posts/jetpack-which-turned-into-a-medium-range-missile.rst
@@ -0,0 +1,165 @@
+title: Jetpack which turned into a medium range missile
+categories:
+ - bugTriage
+ - computer
+ - jetpack
+date: 2010-01-13T08:24:00
+tags:
+---
+
+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):
+
+.. image:: http://3.bp.blogspot.com/_de4d8QAtRzI/S02Crp-5eJI/AAAAAAAAArA/XnOFugLY36c/s400/plain-top.png
+ :scale: 66%
+ :align: center
+ :target: http://3.bp.blogspot.com/_de4d8QAtRzI/S02Crp-5eJI/AAAAAAAAArA/XnOFugLY36c/s1600-h/plain-top.png
+
+and this is the middle part of the page:
+
+.. image:: http://4.bp.blogspot.com/_de4d8QAtRzI/S02DH7hx2GI/AAAAAAAAArI/Yx1MhuJ2qxI/s400/plain-middle.png
+ :scale: 66%
+ :align: center
+ :target: http://4.bp.blogspot.com/_de4d8QAtRzI/S02DH7hx2GI/AAAAAAAAArI/Yx1MhuJ2qxI/s1600-h/plain-middle.png
+
+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:
+
+.. image:: http://3.bp.blogspot.com/_de4d8QAtRzI/S02iMr01OBI/AAAAAAAAArQ/Z872aTFGqlg/s400/jetpacked-top.png
+ :scale: 66%
+ :align: center
+ :target: http://3.bp.blogspot.com/_de4d8QAtRzI/S02iMr01OBI/AAAAAAAAArQ/Z872aTFGqlg/s1600-h/jetpacked-top.png
+
+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": "ajax@example.com"
+ },
+ {
+ "regexp": "xorg-x11-drv-(nv|nouveau)",
+ "addr": "bskeggs@example.com"
+ }
+ ],
+
+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).
+ toLowerCase());
+
+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:
+
+.. image:: http://1.bp.blogspot.com/_de4d8QAtRzI/S02qu8tq9dI/AAAAAAAAArY/KReUQp2Pw0g/s400/jetpacked-middle.png
+ :scale: 66%
+ :align: center
+ :target: http://1.bp.blogspot.com/_de4d8QAtRzI/S02qu8tq9dI/AAAAAAAAArY/KReUQp2Pw0g/s1600-h/jetpacked-middle.png
+
+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.
+
+.. _`the story`:
+ http://ehsanakhgari.org/blog/2010-01-12/bugzilla-made-even-more-awesome
+.. _`the jetpack`:
+ http://mcepl.fedorapeople.org/scripts/install-bugzillaBugTriage.html
+.. _`Greasemonkey script`:
+ http://mcepl.fedorapeople.org/scripts/bugzillaBugTriage.user.js
+.. _`Fedora BugZappers`:
+ https://fedoraproject.org/wiki/BugZappers/Tools
+.. _`one JSON file`:
+ http://mcepl.fedorapeople.org/scripts/BugZappers_data.json