Archive for the ‘lang-en’ Category

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

Friday, August 30th, 2013

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.

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

Friday, August 23rd, 2013

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.

Colors!

Monday, August 19th, 2013

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

GNOME Shell with interesting colors

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

Friday, August 16th, 2013

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

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

Friday, August 2nd, 2013

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!

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

Friday, July 26th, 2013

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

Fedora 19.

Wednesday, July 24th, 2013

Two weeks ago I erased the harddisk on my Fedora machine and installed Fedora 19 from scratch. I was tempted to give Mageia a try instead, but as it’s my main machine which I also use for work I tried to minimize disruption by not trying out new stuff.

My work (bug management) can be described as constant switching between browser (Firefox) with some custom Greasemonkey scripts for triaging bug reports, email application (Evolution) with many filters sorting mail into folders and tagging it, IRC (xchat), text files (gedit) and some gnome-terminal windows. Hence that’s my main focus of interest.

All in all GNOME 3.8 is really fast (considering this laptop is more than five years old) and looks great even in its details. Compared to the “classic” GNOME2/Windows95 user interface and workflow I don’t face any big differences that would require much relearning (but I’ve ran gnome-shell on my other machines before).
With gnome-panel I had application launchers in the top panel that I clicked with a mouse, now I have them in the dock in gnome-shell and start them once at the beginning of the session. For the rest I prefer using the keyboard: For applications that I don’t have running all of the time it’s faster now to start them, by pressing the Super key to get to the overview, typing the first letters, and pressing the Enter key (in gnome-panel this required cumbersome pressing of Alt+F2 plus additional pressing of Tab for autocompletion). I like gedit’s “Quick Open” a lot which allows typing a filename to open that file, without the need to know its location.

The rest of this blogpost only lists those small problems I encountered.

Evolution‘s connection to GMail is way more stable than it was in 3.2, and local filtering works more reliably and does not accidentially sometimes reset mail status to read anymore. Unfortunately importing my large Evolution backup file repeatedly ignored my account settings so I had to set them up manually.
Evolution’s constant freezing when filtering mail triggering gnome-shell’s “not responsive” dialog was quickly worked around by the developers for upcoming version 3.8.4, together with an ical invitation rendering crash fixed. However, even after setting physical folders for Junk and Trash for my GMail account (and filing a ticket to cover this recommendation in the Evolution user documentation), the IMAP+ account implementation sometimes manages to completely reindex a mail folder from scratch which can take a few minutes when you have 85000 messages in that folder. It also seems like I have lost the ability to close Evolution’s error messages by keyboard. WebKit now renders mail instead of ancient GtkHtml which makes everything feel way faster.

gnome-shell freezing and some graphical artefacts (which implies that it’s not gnome-shell itself to blame) have gone after cleaning my fan, now this only happens after a few days due to high memory usage which means I should identify which gnome-shell extension(s) to blame, and uninstall them.

Still no idea how to stop the computer from suspending when the lid is closed nowadays – user documentation needs an update and probably requires some logind magic.

The idea to have modal password dialogs feels pretty stupid when you might have that password saved in some textfile that you now cannot access (terminals to the rescue!) but some developers disagree. Same for missing IRC notifications in the message tray as nothing is blinking anywhere anymore – I’m forced to press Super+M from time to time to realize that colleagues wanted to chat with me a while ago, on the other hand I get less distracted which is very nice when you actually want to get work done.

Furthermore, something in latexmk seems to be broken so I fall back to compiling bibtex and latex documents a few times by hand to link against each other. And Rhythmbox seems to not play my manually added streams for some reason, but it does not crash anymore when starting it for the first time like in Fedora 16.

All in all pretty happy with GNOME 3.8. From past experience of installing a Linux distribution I expected bigger problems – I guess I need to accept how good and nearly flawless everything has become through all those years.

Same procedure as lastevery year, this time even in the center of Europe:

GUADEC

See you there?

Bugzilla Tips (VI): Creating reports and tables

Friday, July 19th, 2013

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.

Quite often I want to quickly check how things are going for specific projects, teams and individuals. Bugzilla’s reporting functionality provides some basic functionality for that. Go to Reports (a link in the sidebar on Wikimedia Bugzilla, and in the footer at the bottom of other standard Bugzillas):

bugzilla-tips-reports1

Click on Tabular Reports:

bugzilla-tips-reports2

You will get the usual advanced query interface, with additional settings at the top:

bugzilla-tips-reports3

One common usecase for me are tables displaying the severity × priority numbers for bug reports of a specific product or component. For this, I set the “Vertical Axis” field to “Priority” and the “Horizontal Axis” field to “Severity”, and in the interface below I choose one Product (in this example: “Datasets”) and set the Resolution field to “—” as I am only interested in unresolved reports. After clicking the “Generate Report” button I get this table:

bugzilla-tips-reports5

Of course you can also select several products by setting “Multiple Tables” to “Product”.

Another usecase is to check which individuals are set as assignees for how many bug reports whenever I wonder if things scale. For this I set “Vertical Axis” to “Assignee”, leave “Horizontal Axis” blank, leave “Product” blank (so the results are global) and set “Resolution” again to “—” (as I am only interested in unresolved, open reports):

bugzilla-tips-reports-assignees

Click on the table headers to sort the columns.

Or if you have Voting enabled in your Bugzilla, you can get a list how many reports have which number of votes by following the steps above by setting “Vertical Axis” to “Votes” instead of “Assignee”.

Note: Saved reports, similar to saved searches, are available from Bugzilla 4.4 on.

Bugzilla Tips (V): Saved and shared searches

Friday, July 12th, 2013

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 find yourself running the same (or very similar) searches in Bugzilla from time to time, you might want Bugzilla to remember your search at the bottom of the list of search results:

bugzilla-tips-columns-saved

Enter a descriptive name in the text field behind “Remember search as” and click the “Remember search” button:

bugzilla-tips-saved-searches2

Bugzilla will confirm the successful creation:

bugzilla-tips-saved-searches3

Your search will now be available as a link in the sidebar of Wikimedia Bugzilla, or in footer at the bottom of other (standard) Bugzillas:

bugzilla-tips-saved-searches5

If your query could also be useful for other Bugzilla users (e.g. members of your development team), you can share your saved search. Go to your preferences (a link in the sidebar on Wikimedia Bugzilla, and in the footer at the bottom of other standard Bugzillas):

bugzilla-tips-user-watching1

Click “Saved Searches”:

bugzilla-tips-saved-searches4

Here you can share your search by enabling the “Share With a Group” checkbox, or also display saved searches that other users have shared:

bugzilla-tips-saved-searches4

Bugzilla Tips (IV): Searching for empty fields

Friday, July 5th, 2013

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 you want to search for a specific field being empty, e.g. bug reports without anybody on the CC list.
If you go to Bugzilla’s advanced search and scroll down to the “Custom Search” (called “Boolean Search” in older Bugzilla versions), you can use “matches regular expression” and respectively “does not match regular expression”. Regular expressions (regexes) are powerful patterns to match a certain string (the corresponding Wikipedia article provides more information).

To find all bug reports that have no keywords, enter this:

Keywords | matches regular expression | ^$

^$ is the regular expression for an empty string.

As written before, regexes are very powerful. For example, you could also search for comments in Bugzilla that contain inline Git-formatted patches by using Comment | matches regular expression | —[[:space:]].+[[:space:]]\+\+\+[[:space:]].+[[:space:]]@@[[:space:]].+@@[[:space:]]

Comment | matches regular expression | ---[[:space:]].+[[:space:]]\+\+\+[[:space:]].+[[:space:]]@@[[:space:]].+@@[[:space:]]

As can be seen, the MySQL database requires using [[:space:]] instead of \s for a whitespace character, see its documentation.