You can also follow a number of our contributors (some of whom don't blog) on Twitter.
Autolinkification
Bugzilla comments are, by default, plain text – so typing <U> will produce less-than, U, greater-than rather than underlined text. However, Bugzilla will automatically make hyperlinks out of certain sorts of text in comments. For example, the text http://www.bugzilla.org will be turned into a link: http://www.bugzilla.org. Other strings which get linkified in the obvious manner are:
- bug 12345
- comment 7
- bug 23456, comment 53
- attachment 4321
- mailto:george@example.com
- george@example.com
- ftp://ftp.mozilla.org
A corollary here is that if you type one or more bug numbers in a comment, you should put the word “bug” before each of them, so they gets autolinkified for the convenience of others.
But also, if you have some text you want linkified in this way, perhaps for use in a blog post, status report, wiki page or other place, you can use the handy linkifier, which will do exactly that for you.
BMO in 2016
Stuff that landed in 2016 Here’s a sampling of improvements to BMO that were launched in 2016. Improvements to bug-modal We’ve continued to refine the modal bug view, aka the “experimental UI”. The BMO team fixed 39 bugs relating to the new interface in 2016. We’ve got a couple more blockers before we make the modal view the default, which should happen in the middle of January. We know there are a still a few outstanding bugs and some missing functionality, so we will leave the standard view available for a little while, at least until all the blockers of bug 1273046 are resolved.Installing Bugzilla on RHEL/Centos 7.x
One recurring subject on the bugzilla support mailing list is the installation of the Perl modules that Bugzilla requires to function. When you are installing on a Linux distribution, the recommended course of action is to use the packages supplied by the distribution. But, on some distributions, these can be of a version lower than what is required by Bugzilla.
One such distribution is RHEL. Version 7 came out in 2014 and its long support life cycle make it popular for people to use it as a base for their bugzilla instance. Using Bugzilla 4.4 is easy because all Bugzilla's mandatory Perl packages are available by default but Bugzilla 5.0 came out after RHEL7 was released and a number of Perl modules aren't available or are outdated. Users then try to install the missing modules themselves, which is something easy to get wrong. I decided to see if this could be made simpler.
My first step was to see if the modules could be supplied in EPEL, a third-party software repository for RHEL and CentOS but some of the modules concerned are in RHEL which makes them impossible to update via EPEL. Another solution is the use of Fedora's COPR, an easy way for Fedora developers to maintain third party repositories for Fedora and/or RHEL.
It took some amount of tweaking to find the package versions that allow you to run Bugzilla 5.0.x without replacing RHEL7's entire Perl stack but the end result is here. Activating a COPR repo is pretty straightforward:
- dnf install dnf-plugins-core
- dnf copr enable eseyman/bugzilla-5.0
At which point, you can install bugzilla just like any other application:
- dnf install bugzilla
The bugzilla package will be updated everytime a new version of Bugzilla is released and its support will end when the Bugzilla developers end support for the 5.0 branch.
BMO's database takes a leap forward
For historical reasons (or “hysterical raisins” as gps says) that elude me, the BMO database has been in (ughhh) Pacific Time since it was first created. This caused some weirdness on every daylight savings time switch (particularly in the fall when 2:00-3:00 am technically occurs twice), but not enough to justify the work in fixing it (it’s been this way for close to two decades, so that means lots of implicit assumptions in the code).BMO in 2015
It’s been a whole year since my last BMO update, partly because I’ve been busy with MozReview (and blogging a lot about it), and partly because the BMO team got distracted from our goals by a few sudden priority changes, which I’ll get to later in this post. Plans from 2014 Even with some large interruptions, we fully achieved three of our five goals for the year and made good progress on a fourth.Better Bugzilla Documentation
The recent release of Bugzilla 5.0 was the first release sporting the new, improved Bugzilla documentation, which has been moved from DocBook XML to reStructuredText to make it easier to edit and so more likely to be up-to-date :-).
Readers of this blog may be particularly interested in the User Guide. Feedback on the new docs is welcome, particularly suggestions for where it is lacking – please use the bug filing link at the bottom of each docs page.
New Modal UI for show_bug on BMO
For the past few months, a new experimental modal bug view has been available on bugzilla.mozilla.org. This hides a lot of complexity both through being read-only initially, and also through having expandable and collapsible sections. It is also quicker and less resource-intensive to load. It requires you to click an “Edit” button, which reveals much more UI, when you want to do more than the common operations – add a comment, CC/NI people, or change the Status or Resolution. It is also more dynamic – for example, there are no more interstital pages when moving bugs between Products, because when you change the Product, the new lists of Components, Milestones etc. load into the widgets automatically.
A picture is worth a thousand words. Here’s the initial view:
And here’s the Edit view:
You can enable it in the Preferences – change “Use experimental user interface” to “On”.
Thanks to glob for doing the hard work on making this happen. This view has not yet made it upstream to Bugzilla itself.
R.I.P. api-dev.bugzilla.mozilla.org
Complaining about bugzilla.mozilla.org (BMO) is a Mozilla project activity as old as the hills. Back in 2009, it was realised by the Foundation that to make everyone happy was (and still is) an impossible task, and I was given a mandate to “help people solve their own problems”. So around September 2009, I released the first version of my Bugzilla API proxy software, BzAPI. This software presented a clean, well-documented RESTful interface on the front end, and did all sorts of things on the back end (XML, CSV, RPC, HTML scraping) that developers no longer had to worry about. We made a dev server VM for it so people could try it out – api-dev.bugzilla.mozilla.org.
It was popular. Extremely popular. People started building things, and then more things, all of which depended on this server for Bugzilla data. For various reasons, IT never got around to building a production instance, and so over the last five years, I’ve been maintaining this core piece of Mozilla project infrastructure, which was depended on by TBPL and many, many other tools which interfaced with Bugzilla. At its peak, it serviced 400,000 requests per day.
Over the intervening years, BMO itself acquired a REST API which slowly became more capable, and then a BzAPI-compatible API shim was implemented on top of it by the excellent dkl, so people could change their code to access BMO directly just by updating the endpoint URL. After a few false starts, requests to api-dev.bugzilla.mozilla.org are now served directly by BMO, via that shim code. Earlier today, the api-dev VM was finally powered down.
Here’s to you, api-dev. Good job.
Bugzilla Has New Documentation
The Bugzilla team recently finished a big project to update, rewrite, improve and centralize Bugzilla’s documentation. You can find it at http://bugzilla.readthedocs.org/. In particular, there’s a User Guide which will be useful to, er, Bugzilla users.
If you have suggestions for further improvements to the documentation, please let the team know.