“Grab the nearest book, open it to page 23, find the 5th sentence, and post its text along with these instructions. Point back to where you got the idea so that we can follow the threads.”

So, I did and funny things, the nearest book was Bible (honestly!). So, it is “Připravil jim hostinu, dal napéci nekvašené chleby a pojedli.” For those who don’t understand my beautiful native language, it is Genesis 19:3, which is in NASB translation: “[…] he prepared a feast for them, and baked unleavened bread, and they ate.” Nice text, thinking about it. I am getting hungry.

A congregation where we are members organized yesterday a benefit concert for the relief of the hunger in the Horn of Africa. Our pastor, being American, immediately asked me and two other Czech members of the congregation before the concert, whether he shouldn’t say something about Mr. Havel. We somehow stood there helpless and in the end we didn’t do anything special (as far as I know). Then we Czechs were kind of ashamed how we don’t have a proper procedure for case of death of beloved politician. It happened so rarely in this land .

I was thinking whole day how to continue in this post. I was thinking a lot about how everybody ignores in my opinion the most relevant message of Mr. Havel for us, which is the life in truth (and thinking about some comparison with the over-celebrated life of virtual hero Steve Jobbs), how our virtual life we all live is so different from the Lebenswelt. However, I was struggling to find a proper formulation and never written anything.

Then I looked at CNN page for some inspiration and found this:

I think the idea of report about Mr. Havel’s being completely encircled by the reports of the death of Kim Jong Il would fit well into some of his best dramas.

Thank you Mr. Havel.

First of all, it is not like there isn’t any information available already. We as a BugZappers team tried to collect as much information as possible so anybody who would like to join our ranks would have something to chew upon without us repeating it again and again. So, there is How to Triage page and other pages coming from this navigation page (e.g., you are expected to know bug workflow by heart if drawn in the midnight from your bad).

Queries

Probably the most important thing which can help you to survive a terror of the never-ending inflow of new bugs are well prepared queries. Red Hat Bugzilla (or any other bugzilla for that matter, as far as I know), doesn’t have a really good way to create coarser (or finer) organization of bugs than on the level of components and products. The situation is especially bad, because products are occupied by, well, products (like Fedora, RHEL, etc.), so in fact the only classification of bugs we have is on the basis of components. Which is obviously crazy huge group of bugs for some components (kernel) and too little for many others. Other options (using keywords in whiteboards, for example) requires much manual additional work (although we use it as well, see below for Xorg bugs categories).

The only way I found how to make dissecting bugs in useful ways possible is by using queries. It is normal state of things for me to have more than 50 defined queries in the bottom of my bugzilla pages. As an example (and possibly foundation of your further development) I could present you this search. Notice that it selects just some components of bugs (using a regular expression), eliminates bugs with needinfo flag set (which is thus a very important variable to care for), and eliminates already Triaged bugs. Of course, this is just a basic search which can be further narrowed by selecting only bugs in some states (although bug triagers deal mostly with NEW bugs), bugs changed in the recent time (when the time is short, it is probably better to deal with the active bugs, not stale ones), bugs for some versions of products, etc.

Firefox addon

Although there has been concerned spent lately on making bugzilla work better for developers, it is still true that its user interface is (if for anybody) optimized for users and so there is little help for avoiding repetitive work. In order to make my work with bugzilla more palatable, I have created a Firefox addon which provides tools for mechanizing a lot of stereotypic work. For example, reporters in the Red Hat bugzilla have no meaningful guidance when filing Xorg bugs, so many filed bugs are lacking logs and other information which is required for developers to effectively diagnose the issue. Actually, making sure that all this information is provided is the main task of Xorg bug triage (where normal other tasks of bug triage, e.g., deduplication and testing reproducers is hardly possible or completely impossible given the limits on available hardware and knowledge of the code itself).

Back to the firefox addon. The main functionality has been described on this blog, so just in the way of summary. The main point which you need to understand is that almost all functionality can be controlled and substantially changed by editing a JSON file which is loaded on the startup of the addon. Per default it is this JSON, but clicking on “Triage configuration” link you can enter URL of any JSON file anywhere on the Internet. All possible options are switched on in my JSON, which can be used as an example for developing of your own file. Let me go through the main options available in such file.

Most famous and probably still most used are buttons filling standardized comments. That’s the biggest parts of JSON file in the object (using Javascript terminology) commentPackages. The name evokes that there are multiple packages which can be switched on for particular bugzillas (one bug triager can certainly work on multiple bugzilla instances … see configData.enabledPackages for examples how to switch on some packages for particular bugzillas). Each packages contains multiple objects one for each button which looks like this:

"addnoresponse": {
           "name": "NoRespns",
           "position": "topRow",
           "commentIdx": "noResponseString",
           "markTriaged": true,
           "status": "CLOSED",
           "resolution": "INSUFFICIENT_DATA"
      },

Each object has its own one-word name, which serves as an index and id for the button itself. Each object is best understood as a package of commands which will be executed when the button is pressed. Some of these “commands” actually don’t are not commands but metadata (“name” contains the label on the button, “position” shows to the addon where the button should be located), but most of them actually do something. So in this example, “commentIdx” points to the comment string in “commentString” section of the JSON file. For shorter comment texts, button package can contain directly “comment” property with the text itself. Either of these texts can be included in the comment. “markTriaged” will obviously make all necessary steps to make bug triaged, and the remaining two commands will close the bug. “position” deserves a little bit special treatment. It can be either “topRow” or “bottomRow” which means that the button will be inserted into the row of buttons above or below the comment box respectively. “position” property can also contain the ID of the element after or before which the button should be included (such string starts with “+” or “-” before the ID string). So for example, “addexternalbugid” package contains "position": "+external_bugs_headline", which means that the button should follow HTML element with “external_bugs_headline” ID.

After “commentPackages” and “commentStrings” sections, the next one is “configData” which is a collection of various configuration options. I have in my JSON file almost all of possible ones on. I will return to this configuration section in a minute, but now let me just the mention the last section “constantData” which contains various constants for Xorg bug triagers, and which you should probably just take for your JSON.

Back to the “configData” section. The biggest object (at least in my file) is “killNodes” which is an object which for each bugzilla instance where the triager is supposed to work lists IDs of all elements you would like to remove from the page (some people especially from Mozilla complained that there is just too much stuff on every page, so that for some people the bugzilla is almost useless, but I had to admit I used it well even with bugzilla.redhat.com). “downloadJSON” contains URLs for additional data files which can be loaded for data which are just too big to be included into “constantData” section (take a look at that file). “suspiciousComponents” is for situations when reporters continuously file bugs into components which are there just for legacy or organizational reasons (xorg-x11 and xorg-x11-drivers). The last is set of couple of Booleans, which directly allow some features of the addon, which are usually not useful for “normal” bug triagers, but were useful for me:

parseAbrtBacktraces

This is mostly legacy option, for large piece of functionality, which pulled just a important part of backtrace from the attached abrt-produced log.

submitsLogging

This is a switch for a functionality which is completely useless for anybody who is not hired for being a bug triager. This addons could ask you for every click on the Submit button to provide short message, which could be then collated into something which goes to my weekly status report. Obviously it should be set to false for almost everybody.

verboseInlineHistory

This is a switch for unfinished attempt to merge in functionality from Bugzilla Tweaks functionality of which was later included into the upstream bugzilla itself.

XorgLogAnalysis

This is a tool which could be very useful for any Xorg bug triager. However, it is kind of dangerous, because if misused it could lead to quite sloppy work. What it does is that it adds to every Xorg.0.log (and dmesg output) a button which makes the addon to run the log through regular expressions which selects lines which can be interesting. Obviously it is useful for fast overview of what’s going on, but certainly detailed inspection of the log is required for any decision.

So, this is finally written down documentation for the mythical JSON file, which I promised for so long.

A bit on process of treating a bug

I will skip technical issues (they are described reasonably well on the above mentioned BugZappers pages), but let me add here couple of notes on the background of the process. First of all, although bug triage is kind of lonely job, we stand on shoulders of some giants (or at least we could if we knew about them). Luis Villa (former bugmaster of Ximian and Gnome project) has a nice collection of his presentations and talks. Highly recommended. Also a lot of discussion about bugs management (obviously) happens in the Bugzilla community, for which Bugzilla Planet is a great entry point (or you can go all the way to Mozilla Planet)

(… to be continued …)

So, my script generates from these two JSON files

{
    "a": 1,
    "b": 2,
    "son": {
        "name": "Janošek"
    }
}

and

{
    "a": 2,
    "c": 3,
    "daughter": {
        "name": "Maruška"
    }
}

this result

{
    "append": {
        "c": 3,
        "daughter": {
            "name": "Maruška"
        }
    },
    "remove": {
        "b": 2,
        "son": {
            "name": "Janošek"
        }
    },
    "update": {
        "a": 2
    }
}

(yes, it should work correctly with Unicode strings). If anybody has any comments on the script or (especially) on the output format, let me know. Of course, patches welcome (I have forgotten to state the license, but let’s say MIT/X11 and if you want anything else, let me know as well).

Also, if anybody wants to get into super boring debugging/refactoring task, then the branch rewrite_xdiff has syntactically correct, but non-working port of XDiff Java program. See the original XDiff paper to see what beauty is (well) hidden there.

In this situation I started to think. I had some complaints about N900 already and I started to think about jumping the boat anyway. The biggest one being that the hardware was apparently not powerful enough to run applications I wanted to run. 256MB is just not enough for Python applications (e.g., an excellent gpodder which I sorely miss now) not mentioning Firefox (which is for many reasons condition sine qua non for me). When I run these two together, whole machine changed into something unbelievable. Of course, I was also worried about the future of the platform, now when the mission of Nokia is to sacrifice itself on the altar of saving Microsoft phone OS (or whole Microsoft?).

So, I have asked my contact person with my phone carrier and I was offered subsidised Samsung Nexus S for around 4,000 CZK ($225). I have agreed and week later I got it by mail. The first impression was great … comparing to the N900’s brick-like design (and weight ), I got a slim gorgeous curved beauty. Given my FLOSS fascism I was decided to put CyanogenMod on it asap, which I managed to do in less than an hour or two. Which given I had absolutely no knowledge about unlocking, rooting etc. of phones (a witty remark about honest phones having nothing to hide to be inserted here), and some troubles between udev and USB cable seems like pretty decent time to me.

Whole phone and Android seem comparing with N900 like a finished end-user product, comparing to sometimes hairy and hackish N900. There are no obvious gaps in the basic applications (who in the world thought that the Maemo calendar is supposed to be taken seriously?) and I was nicely surprised that the lock-in to Google Apps could be avoided and connecting to my own server (Zarafa 7.0.1 via Activesync) was completely painless (switching to open protocols, i.e., IMAP, CalDAV, and CardDAV, to be resolved later, but currently I have a working setup).

Also, Firefox on my phone works quite well and I can happily use it as my default browser (so far, I am on Aurora, and contemplating switch to Nightly).

So, that’s a good part. Now for the bad. It is like going through the beautiful meadows and from time to time fall into deep whole with mud and other junk. I heard in the past couple of years many complaints about Pulseaudio. Well, I have to say there are worse things than Pulseaudio. For example, not having Pulseaudio at all, which is the case with Android. So, suddenly instead of the integrated experience, I had to learn about HFP and HSP, A2DP and similar magic (and see bugs like this one, or this one; I am encouraged that these are most likely duplicates, because apparently bug triage at the Android issue tracker is even worse than in the Red Hat bugzilla ). So, now I have to battle with silly applications like BTmono while with N900 whole listening over BT headset Just Worked™ (needless to say, that free BTmono is just a crippleware made to induce users to buy a better one; those things didn’t happen with my Maemo repos either). And even BTmono doesn’t work correctly, so when I listen to the podcast, I cannot telephone.

Second thing where N900 is clearly better than Android is the core function of the phone. Telepathy just rocks. Apparently Gingerbread made a breakthrough and it integrates at least a SIP client, however, surprisingly Google’s phone doesn’t include native support for Jingle over GTalk. I won’t mention for friends of free software native support for Skype at N900. Whenever I heard on some TWiT podcast how they discussed whether it would be possible to add Skype application to iPhone/Android/something I was amused because of course it was always included and well integrated in my previous phone (it is just a bit in the Maemo’s Addressbook which decides which protocol is used). The same goes for instant messages, and after a year of using N900 you will have a hard time to explain me why in the world I should I care about the difference between ICQ messages, IRC, Jabber, or even SMS message.

The third sad story are FLOSS programs for Android. I thought that given the huge number of users and developers working on Android the situation should be same or better as on almost abandoned (or actually completely abandoned) Maemo. And yet, it is not so. Relation between free software and Android seems to me like a hopeless effort to reinvent the wheel. Software repositories, packaging community, isue trackers are in the Linux world all invented, working, and boring. I am not sure if I found everything but it seems to me that the biggest free Android repository f-droid is just a WordPress blog. Feels embarrassing. There is no community of package managers, no issue tracker, nothing. I guess backtraces from the apps also go to nowhere, right?

Moreover, I have a deep suspicion about the quality of FLOSS apps for Android. The second most important activity for me to do with my phone (or even the most important one, measured by the time I spend with it) is listening to podcasts. I know there are some paid-for apps which are probably pretty good, there is Google Listen (which is non-free and even more binding to the advertising agency, aka AA, ecosystem) which seems to work pretty well, and there are … as far as I was able to find so far two FLOSS apps (I don’t count PonyExpress, because AFAIK it is just one-producer tool; LazyWeb, can you suggest me other application?): SwallowCatcher and Car Cast. Testing of the second one was fast … podcatcher which doesn’t support import of OPML file with my current podcasts is out. So, now I have SwallowCatcher and I hate every moment I have to deal with it. I have to be fair, this is quite obviously pre-alpha release thing, so I shouldn’t be too harsh on its author, but given it is the only app I found, it makes me really sad. Is it just problem of the underlying libraries or the author’s problem it is not able to restart interrupted download? Combined with the fact that exactly during the download the app crashes constantly (so I have to try download of one show three times on average)? And yes, my wi-fi connection is quite crappy on my home network, but that’t probably just because Nokia can do much better hardware than Samsung, which was expected, and I won’t hold it against Android.

I understand that multitasking on Android is broken^H^H^H^Hlimited, but playing of the long podcast just to happen in background. When I send SwallowCatcher to background (by pressing Home key) playback stops. Fortunately it stores the downloaded files so that Google’s Music is able to find them, and that works correctly, but I shouldn’t have to do it manually (e.g., gpodder just doesn’t pretend and uses a system music player for the actual playback).

Talking about an embarrassment, this post is way too long and I should stop it, and it structure is awful. Oh well. I will rather send it out now and not keep it in the Drafts folder anymore.

While getting used to my new Android phone (which will be subject of another post(s)) I have found in the f-droid repository application Tiny Tiny RSS Reader, which is a reader application for Tiny Tiny RSS Reader, a RSS reader as webapp (aka „personal Google Reader”). I have been suddenly attacked by my periodic feelings of shame for still using (and preferring) good old email to all those current hip, web 2.* AJAX webapps. So, I have installed the program on my server, added the following to my fcontexts for SELinux, started update-daemon and run it.

/var/www/tt-rss/.*\.php? all files \
    system_u:object_r:httpd_user_script_exec_t:s0

Whole the app worked more or less as advertised, but I have in the end switched back to my old crusty rss2email. Here are the reasons:

• First of all that Android didn’t work in the end. Changelog for 1.08 says it “Fixed connectivity-problems (no more endless waiting with spinning activity-wheel)”, but that’s exactly how it looked with 1.08 for me. I wasn’t able to find any help neither on fora, nor on IRC, so no phone app for me. On the other hand, email works just fine on the Android, so off-line access to my posts is already available.
• I finally admitted that Simple HTML in Thunderbird of rss2email messages (with HTML on in rss2email) is the best reading experience out there. I really don’t like all those web apps which try to cram all user interface into the webpage, so for reading there is only tiny rectangle in the middle with tiny characters.
• Web interface itself wouldn’t be the problem, but tt-rss contains also update-daemon which is written in PHP and runs constantly. It took more CPU and RAM than any of MySQL, apache, zarafa, or postfix. Just say NO to PHP daemons (or any scripting language daemons for that matter; jury is still out on Java daemons, but suspicion remains).

I am glad to be back, and sorry rss2email that I have doubt you.