2014: Plans.

Studying bug management

To my disappointment my university seems to have no expertise available to mentor a diploma thesis about best practices and common problems in open source bug management. After ten years of working in this field there are quite some open questions I’d like to see answered and after reading lots of scientific papers and books I yet have to find one covering the many aspects and personas involved, so why not write it?
I plan to do some case study research across FLOSS projects (and I’m thankful to Mr Riehle of the University of Erlangen-Nuernberg who pointed out a good resource explaining how to properly do this).

If you are by any chance a teacher at a German university and could imagine to mentor such a thesis, please feel free to contact me.

Wikimedia Bugzilla

This is worth a separate blog post soon, so for the time being I just point to my task list and status updates for the latest achievements. I also plan to attend FOSDEM which has a dedicated wiki track this year!

GNOME

There is a documentation hackfest at the end of this month and I hope to work on the Evolution user docs which I maintain, followed by attending FOSDEM in Brussels and DevConf in Brno.

Chennai

I plan to spend quite some time in Chennai this year by visiting several times. Drop me a line if you live there and would like to discuss Wikimedia, GNOME, or bug management!

Posted in computer, gnome, lang-en, misc, non-technical | Comments Off on 2014: Plans.

Mozilla Summit 2013

mozsummit2013

I had the pleasure to attend the European edition of Mozilla Summit 2013 last weekend. It also took place in Santa Clara (USA) and Toronto (Canada), hosting nearly 2000 Mozillians in total.

The session which interested me the most was discussing bugzilla.mozilla.org (bmo) and the relation to upstream Bugzilla development (especially getting more great stuff from bmo into upstream so other Bugzilla instances could use it). I try to follow bmo development (glob’s “push day” posts and the planning page are the most useful resources) and especially the recent bmo experiments with product dashboards, user dashboards and user pages, but getting an overview of all plans “in a nutshell” is always helpful, especially as there aren’t many upstream meetings.

FYI, further plans for the bmo instance include

  • Native REST API
  • moving the code repository from bzr to git
  • UI improvements, more AJAX
  • upstreaming the new bmo skin
  • moving flags to its own database table for performance reasons (flags are heavily used for release management and hence frequently added in bmo)
  • Investigating the use of memcached
  • Integration with ReviewBoard to replace Splinter

Having spent a few years with Maemo and MeeGo, I also loved the discussion and analysis of the mobile market and its players (competitors and potential allies of Firefox OS).

All in all the conference was extremely well organized and very welcoming – lots of smiling faces. I enjoyed discussing best bug management practices with other triagers, but also offtopic stuff like middle east politics or the times of surveillance that we’re living in. And my hotel roommate awoke my interest in profiling the JavaScript of my triage helper tools so they now run way faster.

Know more, do more, do better.

I would like to express my gratitude to Mozilla for inviting me to this event.

Posted in bugzilla, computer, lang-en, mozilla | Comments Off on Mozilla Summit 2013

Shades of Blue

I’m not entirely sure what’s special about my machine (T61 Thinkpad) that makes it lock up and reboot at least once per day without a warning (but sometimes after showing things in blue), but I’ve decided to blame something down the Xorg/Nouveau stack.
Interestingly, SSH’ing onto the sick machine isn’t much help either – when it freezes, cat /proc/kmsg, tail -f /var/log/Xorg.0.log and /var/log/messages, or gdb attached to /usr/bin/Xorg and gnome-shell don’t react anymore and don’t show any “additional” output either. Maybe it’s time to try Wayland? Can’t get much worse. :P

gnome-shell, now with more blue!

Posted in computer, gnome, lang-en | 6 Comments

Bundestagswahl.

Wahlzettel

Ich kann nicht sagen dass ich die Piratenpartei gut fände. Aber ich kann sagen, dass ich sämtliche anderen Optionen noch enttäuschender finde, speziell wenn die Bundeskanzlerin mal geschworen hat Schaden vom Volke abzuwenden, nur um dann keinerlei Meinung zum massenweisen Abhören besagten Volkes durch ausländische Geheimdienste zu haben, und die anderen Parteien zu dem Thema ja auch nicht ernsthaft etwas zu sagen haben.
Da ist mir mein Grundgesetz dann doch zu lieb.

Posted in lang-de, non-technical, politics | Comments Off on Bundestagswahl.

Bugzilla Tips (XI): Reports: Tickets closed last week by resolution

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

This episode goes deeper into Creating reports and tables and Bugzilla’s Advanced Search.

Three weeks ago a development team asked how to get the number of Bugzilla tickets closed in the last seven days by some resolutions (e.g. FIXED, WONTFIX, INVALID, WORKSFORME) while not being interested in the number of tickets closed as DUPLICATE or LATER.

Another usecase for tabular reports in Bugzilla: The vertical axis will display the components which the team maintains and the horizontal axis will display the bug report resolutions:

bugzilla-closedstats1

We manually selected the components of the team in the “Components” list (keep the Control key pressed to make a multi-selection), and selected all resolutions which should be listed in the bug report (see here for the meaning of the “—” resolution). Keep in mind that these resolutions only refer to the current status of the bug reports.

bugzilla-closedstats2

As we only want to know the number of tickets who were resolved in the last week, we need to query for changes of the resolution. This is where the Custom Search comes into play which allows logical combinations of conditions. For our example:

bugzilla-closedstats3

The generated report looks like this:

bugzilla-closedstats4

Though we chose to include INVALID and WONTFIX resolutions in the search criteria above, the table does not have INVALID and WONTFIX columns because no tickets were closed with that resolution in the last week. Similarly there is no row for the “CLDR” component chosen in the search criteria above because no CLDR ticket was resolved in the last week.

Above example explains how to exclude statuses from the table which you are not interested in. If you want all resolutions displayed in the table anyway (and as setting a resolution requires changing the bug status to RESOLVED), you might already guess that there is an easier way by using “Search By Change History”:

bugzilla-closedstats5

Now in case you wonder why setting the resolutions via the custom search is not sufficient and why it is also required to set the current resolution in the “Product / Component / Status / Resolution” lists above as search criteria: It avoids including tickets which already got reopened in the meantime.

If the numbers are slightly different than your expectations, note that until Bugzilla version 4.2, -7d refers to the beginning of the day in the timezone that Bugzilla is set to, not to the last 168 hours. This has changed in Bugzilla 4.4 though, -1d refers to the last -24h while -1ds refers to the start of the day.

Posted in bugzilla, computer, lang-en, wikimedia | Comments Off on Bugzilla Tips (XI): Reports: Tickets closed last week by resolution

Bugzilla Tips (X): Triage helper tools: Greasemonkey scripts

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

If you read a lot of Bugzilla tickets per day you run into some recurring situations. For example, a bug report might miss sufficient information and you want to point its reporter to a wikipage which explains how to write good bug reports, or you clean up older rotting tickets without enough information and while closing them you want to explain to the reporter why you close the report.

In such situations, having some one-click stock answers (or “canned responses” as others call them) can come in handy in order to save time. I’ve been using several Greasemonkey scripts in my Firefox browser over those years. The two Javascript files which I use in Wikimedia Bugzilla are available to everybody in the code repository. They can be checked out by running the command git clone https://gerrit.wikimedia.org/r/p/wikimedia/bugzilla/triagescripts.git
To use them in Firefox, one has to install Greasemonkey, visit the Git web interface of the repository with Firefox and click the “Raw” links. An installation dialog will open. Note that these scripts only work if you have canconfirm and editbugs permissions in Bugzilla.

This is how it looks after installing the scripts:

bugzilla-triagehelpers-stockanswers

In the picture above, I clicked the “[Close:WorksForMe]” answer. An explanatory command (which also automatically picks up the name of the reporter) is added and the status “RESOLVED WORKSFORME” is set.

As time goes by I’ve added more functionality for my convenience, mostly links to places which are related to functionality exposed in the Bugzilla interface:

bugzilla-triagehelpers

Most useful to me is

  • coloring reporters based on their email addresses (I might spend less attention on a report created by an established developer or employee than a newcomer),
  • coloring the component (MediaWiki has hundreds of extensions, and extensions which are deployed on Wikimedia servers might receive more attention than a non-deployed 3rd party extension),
  • a link to search for other reports created by the same user, and
  • a link to a graph of the priority distribution of tickets for the component (to check how realistically priorities are set – if you only have open tickets with high priority for your component, then something is wrong).

While the code of these Greasemonkey scripts would welcome some cleanup and refactoring, it works for me. Plus today I finally introduced a bunch of boolean variables at the top of the scripts so users can easily define which functionality s/he wants to enable (or not). You are welcome to give it a try (and provide patches if you feel like hacking away).

Of course all this functionality could also be added to the Bugzilla code on the server but I do not want to clutter the Bugzilla user interface even more for everybody by default.
Note that there is also a “proper” upstream Bugzilla extension called Canned Comments available since May 2012 which I have not played with yet.

Posted in bugzilla, computer, lang-en, wikimedia | 4 Comments

Colors!

Save the money for LSD when you can have gnome-shell with a KMS kernel bug!

GNOME Shell with interesting colors

Posted in computer, gnome, lang-en | 1 Comment

Bugzilla Tips (IX): Excluding less important reports from search results

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

Sometimes I’d like to exclude certain bug reports from the search results in Bugzilla.
The most common case is excluding enhancement requests (in order to only get “real” bugs) and excluding lowest and unprioritized priorities (the available values for priorities and severity may differ in other Bugzilla instances), to only have more important stuff listed in the results.

Go to Bugzilla’s Advanced Search and select the product/component that you are interested in, as always. In the “Detailed Bug Information” section, select all values which you do not want to exclude from the Severity and Priority fields:

Selecting Priority and Severity values

Posted in bugzilla, computer, lang-en, wikimedia | Comments Off on Bugzilla Tips (IX): Excluding less important reports from search results

Bugzilla Tips (VIII):Using flags to track branches and versions

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

This episode covers an aspect of release management: Branches.
Bugzilla’s support for tracking bugs and bug fixes in several branches/versions has been notoriously bad.

I have seen two ways how software projects using Bugzilla handle this: One way is to clone bug reports and use the Version and Target Milestone fields strictly. Hence one bug report only affects one branch (version), and the very same bug is handled in a separate bug report for a different branch/version.

Another way is to use flags. Flags can have four states:

  • ?: Somebody requested a decision.
  • -: The request was refused.
  • +: The request was approved.
  • By default the field is empty, and no decision is required / the bug report is not affected.

Flags in Wikimedia Bugzilla:

Tracking-branches-flags-wm

Still, using flags requires agreements on workflows, for example after setting “+” (approved) the bug report should only be closed as RESOLVED FIXED once the fix has actually been merged into the branch.

Since version 4.4, bugmail includes an “X-Bugzilla-Flags” email header which allows filtering mail on it. Furthermore, in contrast to keywords, flags can be configured to automatically notify certain email addresses whenever such a flag request is set.

Mozilla Bugzilla even has a more complicated custom implementation of this which covers both testing whether a version is affected and whether a version has received a bug fix, allowing more than the four states mentioned above:

Tracking-branches-flags-moz

If you use a different approach to track branches in Bugzilla, let me know in the comments!

Posted in bugzilla, computer, lang-en, wikimedia | Comments Off on Bugzilla Tips (VIII):Using flags to track branches and versions

Bugzilla Tips (VII): Simpler searching for open tickets only

This posting is part of a series on small and sometimes not-so-easy-to-discover functionality in Bugzilla that makes developers’ and users’ lifes more comfortable. It’s based on conversations with users and developers in the last months.

If you go to Bugzilla’s advanced search and would like to see only those tickets in your search results which are still open, I have seen users selecting all non-closed statuses (like “UNCONFIRMED”, “NEW”, “ASSIGNED”, “REOPENED” etc. – the exact statuses depend on the configuration of your Bugzilla) either with several mouse clicks while holding down the Ctrl key, or by using arrow keys and Shift on the keyboard.
But you can have the same results with one click in the “Resolution” field: Choose “– – –”.

This is how it looks in Wikimedia Bugzilla:

Screenshot from Wikimedia Bugzilla

Only when a bug report gets resolved (e.g. by fixing it, or marking it as a duplicate) it receives a resolution like FIXED or DUPLICATE. Before it does not have any resolution (hence the “– – –”). This resolution is kept for the follow-up VERIFIED status, but if the report gets reopened it is removed again.

And this is how it looks in upstream Bugzilla:

Screenshot from upstream Bugzilla

Posted in bugzilla, computer, lang-en, wikimedia | Comments Off on Bugzilla Tips (VII): Simpler searching for open tickets only