blob: 907047b2acea247570c16ef96af33c511adf6c42 (
plain) (
blame)
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
|
Two types of objects
####################
:date: 2010-07-03T01:05:00
:category: computer
:tags: jetpack, firefox, bugTriage
I was reminded by `the Ehsan’s blogpost`_ of one still not fully
resolved problem with my bugzilla-triage_ script. The principal reason
why I started working on my third rewrite of scripts (still in
jetpack-prototype) was to make the script *really* useful over the
different bugzilla instances (specifically `MoFo bugzilla`_). I have
found lovely variant of `a similar script by Philipp Kewisch`_ which I
wanted to merge in mine.
Philipp uses quite a different style of UI than I do. I am persuaded
that things like `muscle memory and mouse clicks minimalization`_ are
important considerations so I generally prefer a lot of buttons spread
all over the page (or in the places which I think are most appropriate),
Phillip prefers to have a minimal disruptions to the page with just one
scroll-up ``SELECT`` element. The second problem is of course what Ehsan
mentioned: there are just things too different between different
instances which cannot be coded over in one script. Ehsan mentions
interleaving text between commemtns, I could see on the Red Hat bugzilla
methods of XML-RPC (e.g., ``bugzilla.updateAttachMimeType``) which
are very important to me, but most likely not supported in the upstream
code.
In the end I have decided to go after making the script palatable to
everybody by two ways. First of all I have modified my configuration
JSON file to allow adding items to the ``SELECT`` in the style Philipp
prefers, so that I believe his style of bugzilla page modifications can
be done only by the changes in the configuration file.
The second line of attack was to create inheritance of objects. There is
a base object ``BZPage``, which contains methods and properties useful
on all bugzilla instances. And there are two (so far) child objects of
it: ``RHBugzillaPage`` and ``MozillaBugzilla`` (the latter is just
stub). RHBugzillaPage then contains a lot of code which is specific for
`RH Bugzilla`_ but not for anybody else.
This is the idea, but the problem is that I work almost exclusively on
bugzilla.redhat.com (and bit of b.m.o but I cannot do much there) so I
am afraid those two concepts got incredibly mixed together. I would
really need somebody else to start using my code on b.m.o (or elsewhere)
and hitting all those RH-centric warts.
The good news in all of this is that I have finally some real users in
the BugZappers land (Fedora bug triagers) and after some little warts,
it seems to work! Yay! So, now addons.mozilla.org and then. **WORLD
DOMINATION!**
In other news, I have repented and switched the repository back to Git.
So the repository is now available at
``git://git.fedorahosted.org/bugzilla-triage-scripts.git`` (and we have
gitweb_ as well).
.. _`the Ehsan’s blogpost`: http://ehsanakhgari.org/blog/2010-06-29/bugzilla-tweaks-now-available-extension
.. _bugzilla-triage: https://fedorahosted.org/bugzilla-triage-scripts/
.. _`MoFo bugzilla`: https://bugzilla.mozilla.org
.. _`a similar script by Philipp Kewisch`: http://mozilla.kewis.ch/jetpack/bugzilla-comments.html
.. _`muscle memory and mouse clicks minimalization`: http://archive.oreilly.com/pub/a/oreilly/news/zenclavier_1299.html
.. _`RH Bugzilla`: https://bugzilla.redhat.com
.. _gitweb: http://git.fedorahosted.org/git/?p=bugzilla-triage-scripts.git
|
