1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
Jetpack which turned into a medium range missile
################################################
:date: 2010-01-13T08:24:00
:category: computer
:tags: bugTriage, jetpack
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
:alt: plain top of the bugzilla page without any changes
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
:alt: 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:
.. 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
:alt: 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": "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
:alt: 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.
.. _`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
|
