About Boston Miracle, computers and life

So, where's bugzilla-triage-scripts FF extension for FF4, you ask?

2011-03-30T02:12:00.001+02:00

The great Firfeox 4 is out, and the official version of bugzilla-triage-scripts is broken for you? I am sorry. I have a workaround for you, and working on the final solution of the problem.

Let me explain what’s going on in the back office:

bradford:bugzilla-triage (next) $ git diff --shortstat maint
 58 files changed, 8284 insertions(+), 3375 deletions(-)
bradford:bugzilla-triage (next) $

I have rewritten most of the code (almost no line went unseen). The main change is that we are now using the official (not available when i wrote the first version of the script) page-mod module. This required a lot of work, because page-mod provides isolated content-scripts which cannot get directly to the main script (which has chrome-level privileges), but they can only communicate in a very restricted manner with the main script via messages. On the other hand set of content -scripts share the same namespace, so inside of the scripts the situation is much more simple.
Aside from using the official environment instead of my own hack (which I used before), the main advantage is that the chrome-privileged part of the script is isolated from code of web pages (and in the future it will be working even with Electrolysis), that it should be possible to create unit tests for testing the script (which would be awesome, my constant manual going to one particular and hoping that's good enough testing is ridiculous; I have tried it and it worked with much more simple script for mass-closing of multiple duplicates at once). While going through whole code, of course massive amount of small bugs and typos was unearthed and fixed.
I was working so that I should be ready to release FF4 compatible version of my script in the same moment FF4 would be released. However, then something happened … Ehsan Akhgari continued to work on his (mostly b.m.o targetting) scripts, and this time I have managed to get into contact with him, and started to work on including his modules into mine.
So, in the end I cannot release 1.0 version of my scripts yet (which I hoped to do), because they don't have enough testing and they don’t most of the stuff i would like this release to have. However, given that my original scripts (of FF3.* era) are now completely broken on FF4, I have decided what I have (without the Ehsan’s code), and so I have no three official versions of my script:

The version of the script (numbered 0.27) working with Firefox 3.6.*. It is strictly maintenance only, bug reports are welcomed and they will be hopefully fixed fast, but no improvements or RFEs will be accepted.
The version of the script (numbered 0.92) which I originally thought to be 1.0. This is the script I used for couple of weeks with just small bug fixes, so I hope that it should be useful for general public. Of course, bug reports are very very welcome (Fedora login & password are required).
The last version of the script (currently 0.93, but expect updates). This version contains Ehsan’s scripts but with small fixes to make it work on Red Hat’s bugzilla.

So, what can you expect to coming? For example this (it should be in future configurable, so only those who are interested, will use it)

In the end I would need to introduce all functionality contained in Ehsan’s original scripts (also described here).
Updates are not working currently (if anybody is able to troubleshoot, any ideas are welcome), but go and install and use the script.

Oh, really?

2011-03-29T07:54:00.000+02:00

So, spreadfirefox.com which is known to be a PR tool of the Firefox community proudly offers old version of Firefox? (fortunately, these buttons lie, it really leads to firefox.com which offers the real thing). Interesting.

Few thoughts on Gnome 3

2011-03-14T10:00:00.000+01:00

While reading articles like Jon’s or the Nicu’s one (actually, this one is really funny, although IMHO wrong) I have couple of thoughts I would like to write down:

Yes, the user interface will be VERY different. Deal with it! Take this book (find it in the library or in a second hand bookstore) as your good night companion. If you need a professional help, Fedora won’t cover it though.
Yes, given that all Gnome developers will most likely just struggle with crashes and similar lovely stuff until GA, I don’t expect much change in UI, and yes it will be probably kind of “1.0” (hopefully, we’ll do better than KDE 4.0, but who knows?). Deal with it! Yes, I have some pet peeves as well, but I won’t mention them here on purpose.
Yes, there will probably some people who will leave for XFCE/LXDE/twm/Fluxbox or other distros which are not changing in their user interface this release cycle (Debian, Arch, Gentoo?).
No, I am afraid, in the end, it is not possible to do fundamental changes in an user interface in more gentle way.
No, I don’t think the current Gnome2 user interface is the Holy Grail of user interfaces, and I would expect that other DE now holding against the change, will either change in next few years as well (with similar bumpy road on start), or they will become irrelevant (which is not the worst thing to happen … I don’t see Google and Microsoft exactly to fight over Fluxbox, but I know about many happy Fluxbox users).

Aren't Czechs awesome? :)

2011-03-09T11:42:00.001+01:00

Just this made my day:

Yes, numbers are too small, etc. etc.

Video of my GUADEC presentation is now available!

2011-02-22T15:06:00.001+01:00

So, finally being made active by Ehsan, I have cut a relevant portion of GUADEC 2010 video streams and posted it on blip.tv. Slides (not very helpful, I am afraid, the real meat was in demos) are also available. I had constant struggles with microphone falling behind my T-shirt, so sound is sometimes awful.

Enjoy!

Mirror Mercurial repository to git?

2011-02-12T16:01:00.002+01:00

I am a big fan of Gajim, XMPP client and for years I have followed its latest development versions with my packages. Unfortunately, gajim’s development is tracked in a Mercurial repository. Please, understand correctly, I have nothing against Mercurial (and I am apparently not alone), the first version of bugzilla triage scripts were hosted in the Mercurial repository. However, this experience taught me two things. First of all, my head is probably irreparably damaged by git, so I couldn’t get my head around randomly occurring multiple heads constantly erupting in my repository. I was constantly battling with it and generating nonsensical commits just to get rid of them. I never felt like pushing mercurial to the background just to work for me, in the same manner git already worked for me. However, the final nail to the coffin of my efforts to domesticate Mercurial was when I found out that the Jetpack repository itself will be most likely hosted predominantly on github.
So, I have mirrored for years gajim repository on gitorious, and I was not that much surprised when I read today’s blogpost about mirroring mozilla-central in a git. However, I was reminded about Hg-Git plugin. Chris reminded me again about the problem that I need to run git checkout -f from time to time to clean the repository. I was also tickled by the idea of stable commit IDs. The idea that two git repositories converted from the same hg one would be compatible was interesting. However, I haven’t found hg-git that awesome:

Speed ... I like Python, but using dulwich seems questionable at the best. Git users are quite proud about the speed of git, but speed of both hg gexport (the conversion itself) and hg push to git repository is just depressive. Couldn’t somebody make version of hg-git using native C git commands?
Branches ... another thing git users tend to love IMHO are branches. So the fact that hg-git hides all hg heads from me per default and forces me to get back into fiddling with hg bookmarks and heads and all that, doesn’t make me smile. hg-fast-export by default just making all heads into branches makes me much much more happy.
This not complaint just reminder about suggested change of defaults (no I don’t complain, I promised never to fight over defaults ever). Run, don’t just go to your ~/.hgrc and add there
```
[git]
intree = True
```
The original default just, in my opinion, doesn’t make sense.

So, the only objection I have against hg-fast-export is the necessity to do git checkout -f from time to time (and my uncertainty, what would happen if I do hg-fast-export outside of master branch). This script (called git-hgimport) makes me completely happy and secures hg-fast-export future as the converter of my gajim git repo:

#!/bin/sh
set -e

git checkout master
hg pull --update
hg-fast-export --quiet
git checkout -f

And of course, if this script is in $PATH, then git suddenly knows about git hgimport command.
Does anybody out there knows about some better comparisons between hg-fast-export and hg-git?

Culture wars? Why?

2011-01-11T00:22:00.004+01:00

We were living as strangers (both me and my wife were born and now live again in Prague, Czechia) in the United States for couple of years, so I’ve managed to do couple of faux-pas during my time in Boston. One day, in very friendly party, among our very nice and lovely neighbors, I’ve heard one of my neighbors (very nice guy, a budding artist hoping to finally make it in the arts world) to say: “I just cannot stand all those fundamentalists around, I think we should be straight and call them who they are—anti–choice, dictating women what they should do with their body!” He said it with such passion and hatred in his voice, that I cannot hold myself (no, I haven’t had in that moment enough courage to admit that I consider abortion a murder of unborn baby) and replied to something in the sense, that the name calling is not nice, and how he would like to be called “anti-life”. I have never in my life heard such deep silence. All those nice, tolerant, diversity loving Bostonians were looking at me like at a calf with two heads.
I had no time to say, that I think my point of view was more nuanced … I don't think I would support reintroduction of the legal ban of abortion (although I believe that purely from the jurisprudential and legal technology point of view Roe v. Wade and related decisions are examples of very bad ones), I think there are many better ways how to decrease number of abortions than by banning them, etc. I have not got though an opportunity to say it, because once I was labeled as one of them nobody was interested in hearing my opinions. And it seemed to me nobody was really interested in the discussion about (dis-)advantages of the anti-abortion law.
I was just starting my PhD program in Law & Society at the Northeastern University and part of the program were courses in the political science. I have found that there is a big volume of study about cultural wars, the biggest one about the history of the alcohol prohibition movement (if anybody is interested the classical book on the subject, read Joseph R. Gusfield. Symbolic Crusade: Status Politics and The American Temperance Movement. ISBN 0-252-01312-3). The main conclusion of these studies (and this one particularly) is that the focus of the struggle in the prohibition politics wasn’t that much the question of alcohol itself, but struggle for preservation of status of the established Anglo-Saxon society threatened by the ongoing immigration wave of Irish, Italians, and Germans. And best dividing factor between us and them was then the attitude towards alcohol, because there are apparently much more casual non-addicted drinkers of alcohol among these new nations (where for example a glass of wine or beer is standard part of dinner) then in the Anglo-Saxon culture, where much bigger share of population tend to be on extremes in relation to alcohol.
Generalization from the prohibition movement to current cultural wars was then obvious: these are much more status struggles than struggles for the issue itself. Should the America be governed and run by pro-life, marriage defending, gun holding (to mention just few most obvious examples) Bible belt Christians, or by pro-choice, gay marrying, anti-gun “Godless” population of coasts?
Of course, the question is how does this rather obvious conclusion (when you think about it) relates to the topic of this blog. What is the proper Stage four relation to the cultural wars? It seems to me that if we accept these four stages as describing something about the groups in the society (and I have hard time to do it, but for lack of other models, I do accept it), then the fourth stage believers are back in their uncomfortably lonely position: on one side there are stage two conservatives fighting for the “Ol’ time religion” against the slaughter of stage three liberals from the coasts. And our 4th stage believer is somewhere between them trying to question firm conclusions and strongholds of both sides.
One more piece of history: I was in Boston when the Massachusetts Supreme Court allowed gay marriages in the Commonwealth of Massachusetts, and the parliament was discussing possibility of adopting some kind of “defense of marriage” amendment which would overrule the court’s decision. Suddenly whole pro-/anti-gay cultural war was very strictly localized, and the Boston Commons around Beacon Hill (seat of the government in Massachusetts) changed into one big battleground of this cultural war. Majority of participants were local supporters of gay marriage, but there were substantial groups of opponents mostly coming from the outside of Massachusetts. I remember watching the posters of both sides (something about extending human rights from African-Americans to gays, and on the other side I remember slogan “God hates fags” with some Biblical quotations by Westboro Baptist Church of Topeka, owners of the website God Hates Fags). I was thoroughly confused by both sides, which seemed to present these two positions as the only ones possible, and yet I knew very strongly that I would like to be as far as possible from both of them. A friend, apparently battling the same thoughts, said suddenly “This is as close to the Hell as I’ve ever got.”
To be specific and considering the gay marriage issue as an example, let me show what I would think could be a reasonable thinking of a stage four Christian (and of course, I don’t think it is the only one, I guess many of you won’t agree with many of my premises and conclusions; it’s more about a way of thinking than about particular issues). So, first of all I have to declare that I believe homosexuality is a sin (in the sense “missing the best God prepared for us”, not that I would believe homosexuals are bad people). Although I have never struggled with homosexuality myself, I have been actively participating in the Desert Stream Ministries (the inner healing ministry founded and mostly still led by former homosexuals) and I count some former homosexuals as my friends. However, I am also persuaded that beating sinners with a big poster “You are a sinner” usually doesn’t bring healing, and my role is not to persuade gays to give up on their lifestyle, but to be present and willing to help them in the moment they decide they would like to find a way back to the fullness of life God has prepared for them (be it a single life or eventually even marriage).
Given these two premises, I am in the wide arena of possible conclusions with not very certain opinion on possible legislative dealing (or non-dealing) with the matter. If I accept as given, that there are many people who are still living in the homosexual relationship (or in other words, who haven't accepted God’s plan for their life yet), then it would be probably humane to make for them living conditions acceptable. That includes certainly some kind of official acknowledgment of their relationship allowing them wide variety of legal advantages otherwise provided by law for husband and wife (e.g., right to visit each other in hospital, getting sick-leave when caring for a sick partner, inheritance, let’s abstain for sake of brevity from discussion on the issue of adoption by gay partners). I wouldn’t call this legal arrangement “marriage”, because that really signifies approval of what I believe is not a healthy lifestyle, but otherwise I would go long way towards making supportive environment for the life of gay couples.
One observation from this side of the Pond. It is interesting that the “Godless Europe” has in this issue much less problems than people in America. Given the long history of ateism (and tendency towards socialism) most European countries have an institute of some kind of non-marriage official relationship (originally for heterosexuals who didn't want to have anything to do with Church in times when marriages were still closely linked to religious ceremony). They are usually not very popular (I believe every European country has now as an option secular marriages in the town hall), I think many Europeans don't even know such institute exists, but their mere existence made it very easy for most European countries to adopt some kind of registered partnership for homosexuals as an option and (with some exceptions) I don't know about much struggle to open classical marriages to gay couples.
Again, I don’t think this is the only possible solution and I am not willing to defend it with putting on the line my honor, my property, and my life, but I would love to participate in the discussion about these questions with other people interested more in discussion than in cultural wars.
However, even more importantly, I would hope that Christians would be able to distinguish when they are fighting for The Right Thing™ and when for promotion of their status in the society. And I am afraid, many times with many Christian organizations and politicians, I am not persuaded they see it.

I will say just one very crazy thing ...

2010-12-16T13:07:00.000+01:00

Looking at Time's Person of the Year 2010 polls, I think I can see it as clearly as the sun: In two years Facebook will be as dead as AOL is now. Just sayin', and so that this is recorded for posterity.

Living in the avalanche … or unexpected results of one bit

2010-11-08T09:32:00.000+01:00

While fighting with my bugs couple of months ago (around a F14 Beta, IIRC), I got annoyed by number of bugs waiting on being eliminated in EOS with unreplied needinfos. When going through them I discovered to my unhappy surprise that many of these automatically created bugs don’t have needinfo flag set, which made my life even worse. My defined queries filter out bugs with needinfo flag set, because they are not my concern.

Courtesy of DCSL on Flickr

So, I’ve hoped to #fedora-bugzappers to find out what was it that those EOS warnings were not setting needinfo flag. I’ve found that basically just nobody thought about that or something and I was promised that this will be fixed for F12 EOS messages. I returned to my bugs and completely forgot about whole thing.

With the release of F14, the standard EOS message was sent to thousands of bugs at once. Then a strange thing happened: instead of few dozen replies I was used to getting, an avalanche of messages started to flow in. I had to see over hundred messages yesterday and people were confirming bugs being fixed, or not, adding more interesting data and I was completely swallowed by the avalanche of this small tidbits. I was able to unearth some completely forgotten bugs, close tons of duplicates, and revive some bugs which were looking like heading towards sad fate of being EOSed.

Interesting how much one bit matters.

Atompub depression

2010-09-14T17:44:00.000+02:00

So, looking at interesting presentation on Wordpress APIs, I have hit on this slide:

Am I allowed as a friend of Atompub to feel depressed? What happened to the promised world domination?

On the related atompub and depression combination? I have a file with my complete blog in Atom format. Now I would like to create a simple script posting all entries there to Atompub store (let's say blogger, when I use it already)? Of course the condition is that if I add new entries to the Atom file and repost it again only new and updated entries will get published. So, of course I would need the way how uniquely identify each entry be it in the file or in the Atompub store (did I mention that I would like to be able for whatever reason be able to publish the same Atom file in different stores?). Of course, you cry, that’s what <entry:id> was created for! Every entry has its globally unique ID, right?

Except no Atompub store known to me allows you to publish entry with your own ID. Actually you have to remove <id> element before publishing to Livejournal, Wordpress, and Blogger otherwise they will reject this perfectly valid Atom entry, and you have to publish something which is not valid Atom (<id> element is MUST for Atom entry).

So, lazyweb, do you know about any means how to publish my Atom file to blogger without having a separate database of local:published ID relations? If it would be possible to switch to another blogging platform, I’ll switch immediately just because of this.

While collecting links for this post, I have found this. Maybe just depression is what remains for us.

2010-09-08T18:33:00.001+02:00

Adam is right: I am not getting it either.

except of background, I don't change my desktop either,
I don't see much of my desktop under all those icons anyway (I have $HOME as my desktop),
usually most of my time I have desktop hopelessly hidden behind fully maximized Firefox anyway.

bugzilla.gnome.org supported

2010-08-09T05:38:00.002+02:00

So, ticket 38 has been closed, so we have another officially supported bugzilla: bugzilla.gnome.org. When you start bleeding-edge (“nightly” :)) .xpi from my site (Firefox will complain, that the extension is downloaded from untrusted source), then you should have scripts working on bugzilla.gnome.org by eliminating all additional buttons and not adding anything new (scripts default into support for bugzilla.redhat.com). On the bottom of the page you should be able to find a link ”Triage configuration”.
Click on it and to the input enter URL for the Gnome configuration JSON, which is currently http://mcepl.fedorapeople.org/scripts/Config_gnome.json. Restart Firefox, and go back to the bugzilla.gnome.org bug page.
For the script to load, you have to be logged in to the bugzilla (otherwise it won't activate).
I am also not sure, whether the texts of comments, and resolutions being set are correct for bugzilla.gnome.org. File a ticket with fixed JSON file, please.
And of course, I believe that if the scripts happens eventually to be officially supported for b.g.o, Gnome bug triagers will host their own. Or maybe I should rather accept ticket 39 and make only one default JSON? Let me know.

First steps towards support for bugzilla.gnome.org

2010-08-06T07:19:00.000+02:00

After return from Guadec I was greatly encouraged by the interest I've met there. I thought on the spot about making a specific child object for Gnome bugzilla (similar to MozillaBugzilla), which would liquidate unnecessary buttons from bugzilla. However, another request I've got was from Luis and he asked me to get an ability to eliminate unnecessary buttons so he can use bugzilla for his MoFo legal work (which is an interesting idea in itself ;)).

In the end I have decided that it would be actually easy to keep all business logic still in JSON file (and not having some if (this.hostname === "bugzilla.gnome.org") hardwired in the code). So with the current (git, unreleased) version you can add this bit of code into configData of your JSON file

"killNodes": {
     "bugzilla.gnome.org": [
          "stocklinks", true 
      ]
},

and the script will kill element with id 'stocklinks' upon the startup. For Luis, instead of one string, it could be an array with more IDs. So this is the current look of bugzilla.gnome.org in my Firefox

However, while testing the script I found that bgo is still very heavily modified (although apparently not an obsolete one anymore) and my script breaks somewhere. I have fixed one inconsistency (apparently, 'mailto:' is not good enough for their email addresses ;)), but there is still something which breaks generation of new buttons. I'll work on it when I can.

No Github for you anymore!

2010-07-30T02:37:00.000+02:00

Github seems to be somehow broken, and I don't get any reactions about it anyway. So I have killed it. For all bugzilla-scripts project needs use https://fedorahosted.org/bugzilla-triage-scripts/

Thank you

Fixed bugzilla.mozilla.org compatibility problems

2010-07-21T14:12:00.004+02:00

My GUADEC presentation is getting nearer and nearer which makes me push commits in the even higher frequency. Yesterday I have finally fixed compatibility issues with bugzilla.mozilla.org and created default JSON for Mozilla bug triagers, which is just a port of the original Philip’s one.

In other news, I have created mirror of my official

git://git.fedorahosted.org/bugzilla-triage-scripts.git

repo on GitHub. Pull requests and any other means of providing patches are of course very welcome! (Sorry, I don't have a dovecote, so I am not RFC 1149 compatible).

In yet another news, does anybody have any idea, how to make an addon on AMO reviewed? Oh well :(.

World Domination is one step closer!

2010-07-16T11:22:00.000+02:00

My bugzilla triage addon is now on addons.mozilla.org!

And I have already upgraded the version there to 0.13, which stores passwords in the Firefox encrypted password storage and is much more closer to be compatible with other bugzillas.

Two types of objects

2010-07-03T01:05:00.001+02:00

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).

Current status (a week ago) of my bugzilla Jetpack scripts.

2010-06-29T21:42:00.000+02:00

The code is available at fedorahosted (Mercurial repository is also available). There are two branches in this repository:

Branch “prototype” contains production code based Jetpack-prototype (currently version 0.8). From my point of view it is in the maintenance mode, but it is possible that integration with other bugzillas could be done on it, as it is currently the only code which actually works for non-developing public.
Branch “default” contains currently alpha code for new Jetpack-SDK.

The Jetpack-SDK framework is currently not complete, but it is good enough for me to use it for my everyday work (which I am afraid suffers a bit because of work on this script which is supposed to help me ;)). And yes, I had to write some parts of the framework which I hope will be provided by the framework (e.g., I have my primitive version of pageMods in main.js, and there is no good equivalent of GUI as in jetpack.storage.settings; BTW, I have to thank to Ehsan for the inspiration and encouragement).

Jetpack which turned into a medium range missile

2010-01-13T07:24:00.005+01:00

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):
and this is the middle part of the page:

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:

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:

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.