mr mr cote

Educational, Investigative, and Absurd Writings by M. R. Côté

Searching Bugzilla

| Comments

BMO currently supports five—count ‘em, five—ways to search for bugs. Whenever you have five different ways to perform a similar function, you can be pretty sure the core problem is not well understood. Search has been rated, for good reason, one of the least compelling features of Bugzilla, so the BMO team want to dig in there and make some serious improvements.

At our Portland get-together a couple weeks ago, we talked about putting together a vision for BMO. It’s a tough problem, since BMO is used for so many different things. We did, however, manage to get some clarity around search. Gerv, who has been involved in the Bugzilla project for quite some time, neatly summarized the use cases. People search Bugzilla for only two reasons:

  • to find a set of bugs, or
  • to find a specific bug.

That’s it. The fact that BMO has five different searches, though, means either we didn’t know that, or we just couldn’t find a good way to do one, or the other, or both.

We’ve got the functionality of the first use case down pretty well, via Advanced Search: it helps you assemble a set of criteria of almost limitless specificity that will result in a list of bugs. It can be used to determine what bugs are blocking a particular release, what bugs a particular person has assigned to them, or what bugs in a particular Product have been fixed recently. Its interface is, admittedly, not great. Quick Search was developed as a different, text-based approach to Advanced Search; it can be quicker to use but definitely isn’t any more intuitive. Regardless, Advanced Search fulfills its role fairly well.

The second use of Search is how you’d answer the question, “what was that bug I was looking at a couple weeks ago?” You have some hazy recollection of a bug. You have a good idea of a few words in the summary, although you might be slightly off, and you might know the Product or the Assignee, but probably not much else. Advanced Search will give you a huge, useless result set, but you really just want one specific bug.

This kind of search isn’t easy; it needs some intelligence, like natural-language processing, in order to give useful results. Bugzilla’s solutions are the Instant and Simple searches, which eschew the standard Bugzilla::Search module that powers Advanced and Quick searches. Instead, they do full-text searches on the Summary field (and optionally in Comments as well, which is super slow). The results still aren’t very good, so BMO developers tried outsourcing the feature by adding a Google Search option. But despite Google being a great search engine for the web, it doesn’t know enough about BMO data to be much more useful, and it doesn’t know about new nor confidential bugs at all.

Since Bugzilla’s search engines were originally written, however, there have been many advances in the field, especially in FLOSS. This is another place where we need to bring Bugzilla into the modern world; MySQL full-text searches are just not good enough. In the upcoming year, we’re going to look into new approaches to search, such as running different databases in tandem to exploit their particular abilities. We plan to start with experiments using Elasticsearch, which, as the name implies, is very good at searching. By standing up an instance beside the main MySQL db and mirroring bug data over, we can refer specific-bug searches to it; even though we’ll then have to filter based on standard bug-visibility rules, we should have a net win in search times, especially when searching comments.

In sum, Mozilla developers, we understand your tribulations with Bugzilla search, and we’re on it. After all, we all have a reputation to maintain as the Godzilla of Search Engines!

Review Board Preview

| Comments

I know lots of people are very anxious to see Mozilla’s new code-review tool. It’s been a harrowing journey, but we are finally knocking out our last few blockers for initial deployment (see tracking bug 1021929). While we sort those out, here’s something to whet your palate: a walk through the new review work flow.

BMO Mid-2014 Update

| Comments

Here’s your mid-year report from the offices, basements, and caverns of BMO!

Performance

This year we’re spending a lot of time on performance. As nearly everyone knows, Bugzilla’s an old Perl app from the early days of the Web, written way before all the technologies, processes, and standards of today were even dreamt of. Furthermore, Bugzilla (including BMO) has a very flexible extension framework, which makes broad optimizations difficult, since extensions can modify data at many points during the loading and transforming of data. Finally, Bugzilla has evolved a very fine-grained security system, crucial to an open organization like Mozilla that still has to have a few secrets, at least temporarily (for security and legal reasons, largely). This means lots of security checks when loading or modifying a bug—and, tangentially, it makes the business logic behind the UI pretty complex under the hood.

That said, we’ve made some really good progress, starting with retrofitting Bugzilla to use memcached, and then instrumenting the database and templating code to give of reams of data to analyze. Glob has lots of details in his post on BMO perf work; read it if you’re interested in the challenges of optimizing a legacy web app. The tl;dr is that BMO is faster than last year; our best progress has been on the server side of show_bug (the standard Bug view), which, for authenticated users, is about 15% faster on average than last year, with far fewer spikes.

Bugs updated since last visit

Part of an effort to improve developer productivity, in June we rolled out a feature to give a new way for users to track changes to bugs. BMO now notes when you visit a bug you’re involved in (when you load it in the main Bugzilla UI or otherwise perform actions on it), and any changes to that bug which occur since you last visited it will show up in a table in My Dashboard. Read more.

Bugmail filtering

Another improvement to developer productivity centred around notifications is the new bugmail filtering feature. Bugzilla sends out quite a lot of mail, and the controls for deciding when you want to receive a notification of a change to a bug have been pretty coarse-grained. This new feature is extremely customizable, so you can get only the notifications you really care about.

BzAPI compatibility

There have been several broad posts about this recently, but it’s worth repeating. The original Bugzilla REST API, known as BzAPI, is deprecated in favor of the new native REST API (on BMO at least; it isn’t yet available in any released version of the Bugzilla product). If possible, sites currently using BzAPI should be modified to use the new API (they are largely, but not entirely, compatible), but at a minimum they should be updated to use the new BzAPI compatibility layer, which is hosted directly on BMO and sits atop the new REST API. The compatibility layer should act almost exactly the same as BzAPI (the exceptions being that a few extra fields are returned in a small number of calls). At some point in the not-too-distant future, we’ll be (transparently) redirecting all requests to BzAPI to this layer and shutting down the BzAPI server, so it’s better to try to migrate now while the original BzAPI is still around, in case there are any lingering bugs in the compatibility layer.

More stuff

As usual, you can see our current goals and high-priority items for the quarter on the BMO wiki page.

Bugzfeed: Bugzilla Push Notifications

| Comments

A large number of external applications have grown up around Bugzilla serving a variety of purposes. One thing many of these apps have in common is a need to get updates from Bugzilla. Unfortunately, the only way to get notifications of changes was, until recently, to poll Bugzilla. Everyone knows that polling is bad, particularly because it doesn’t scale well, but until recently there was no alternative.

Thus I would like to introduce to the world Bugzfeed, a WebSocket app that allows you to subscribe to one or more bugs and get pushed notifications when they change. It’s rather a small app, based on Tornado, and has a very simple interface, so it should scale quite nicely. It relies on a few moving parts to work, but I’ll start with the basics and explain the whole system later.

The production version is at ws://bugzfeed.mozilla.org. I also made a very simple (and ugly) example app for you to use and examine. A development version of Bugzfeed is available at ws://bugzfeed-dev.allizom.org; it’s tied to the development Bugzilla server, so it’s a good place to experiment if you’re a Mozilla contributor; you can make whatever changes you need to bugzilla-dev without worrying about messing with production data. You’ll need to get someone in #bmo on irc.mozilla.org to reset your password, since we periodically refresh and sanitize the database on bugzilla-dev, and email is disabled so you can’t reset it yourself.

(This makes me think that there should probably be a Bugzfeed instance tied to Landfill; maybe I’ll look into that, in particular if we implement middleware other than Pulse (see below).)

Client commands, responses, and notifications are all in JSON format. The project wiki page has the full list of commands. Here’s a little example of what you need to send to subscribe to bugs 1234 and 5678:

{"command": "subscribe", "bugs": [1234, 5678]}

The server will send a simple response, including a list of all the bugs you are (now) subscribed to:

{"command": "subscribe", "result": "ok", "bugs": [1234, 5678]}

Now you can just wait for notifications to be pushed from the server to your app:

{"command": "update", "bug": 1234, "when": "2014-04-03T21:13:45"}

Wait, you are probably asking, that’s it? That’s all I get?

The short answer is yup, that’s it. You can now use the regular REST API to get further details about what changed.

The longer answer is yup, that’s it, because security. Bugzilla has evolved a very fine-grained security system. We have bugs, attachments, and even comments that can only be seen by a privileged few, due to security, legal, and other considerations. Furthermore, many of the variables involved in determining whether a particular user can see a particular bug/attachment/comment can change at any time: not only can elements of a bug shift between public and confidential, but so can a user’s groups, and the groups themselves. Monitoring for all those possible changes would make this app significantly more complex and brittle, so we opted for the most secure notification, which is also the simplest: just a bug ID and a timestamp. All the other work is handled by the standard Bugzilla APIs.

(You might also be asking “why is ‘update’ considered a command?” and, to be honest, I’m not sure, so maybe that’ll change.)

There are other commands, and some limited caching of changes in case your client disconnects; see the project wiki page for more.


So how does it work? Here’s a system diagram created by contributor musingmario:

Bugzfeed system diagram

The four main pieces (with links to source) are

On the Bugzilla side, the BMO team created an extension which writes the bug ID and timestamp to a table when any bug changes. A simple Python app polls this table and sends all the updates to Pulse, cleaning up the table as it does so.

Pulse is a Mozilla RabbitMQ server with a specific configuration and message format implementing the publish/subscribe pattern. The usage is somewhat Mozilla specific, but it would be pretty easy to set up a similar system or even modify Bugzfeed and the Bugzilla shim to use RabbitMQ directly, or a different AMQP system like ØMQ.

Notifications from all bugs flow through Pulse; it is Bugzfeed, the WebSocket server, that does the filtering for its clients to notify only on subscribed bugs. Subscribing to individual notifications from Pulse is possible via topics, but this requires one channel per bug, so I doubt it would be any more efficient if hundreds of clients are connected to Bugzfeed.

While you could have the Bugzfeed server read directly from the Bugzilla database, eliminating the shim and the queuing system, having an intermediary allows us to easily stand up more Bugzfeed servers if load gets too high, as each Bugzfeed instance would see the stream of changes via its own subscriber queue. We can also easily interface new applications to the notification stream, such as the BMO Elastic Search cluster.

Enough technicalities; go out and play with it! And if you want to adapt it for your own Bugzilla installation, I’d be more than willing to help out.

Moving Bugzilla From Bazaar to Git

| Comments

Or, how to migrate to git using only three programming languages

Another aspect of Bugzilla has been dragged, kicking & screaming, into the future! On March 11, 2014, the Bugzilla source moved to git.mozilla.org. We’re still mirroring to bzr.mozilla.org (more on that later), but the repository of record is now git, meaning it is the only place we accept new code.

Getting over there was no small feat, so I want to record the adventure in the hopes that it can benefit someone else, and so I can look back some day and wonder why I put myself through these things.

Background

The rationale isn’t the focus of this post, but suffice it to say that Bazaar isn’t very widely used, and many projects are abandoning it. Eric S. Raymond wrote a good post on the Emacs dev list about why they need to move from Bazaar to git. The same rationale applies to Bugzilla: “Sticking to a moribund version-control system will compound and exacerbate the project’s difficulty in attracting new talent.”

So, moving on, I started off scouring the Internet to find the best way to perform this migration. One major complication is the fact that we want to keep mirroring (one-way) to Bazaar for at least a while, since the main suggested way to upgrade Bugzilla is from bzr.mozilla.org. It was deemed unreasonable to require existing installations to switch to git to obtain a small security fix, so we’ll continue to mirror changes to Bazaar for some time.

Initial migration

I found a few posts here and there about people who had done migrations like this, but the most useful was a post by David Roth from last year that detailed how to preserve Bazaar’s commit metadata, specifically bug-tracker metadata, which Bugzilla has used on virtually every commit since switching from CVS. It involves using the --no-plain option with bzr fast-export and then translating the output to something git understands.

Interestingly, Roth’s translation script was written in C#, not my personal first choice for such a task (or any, really, since I don’t generally develop for Windows). However it compiled fine under Mono, so I could run it on a Linux box. Something I learned, though, is to not try this kind of thing on OS X, where, by default, the filesystem is case-insensitive.

As much as I’d prefer to deal with a language with which I am more comfortable, I dislike duplicated effort even more. I used Roth’s C# script as a basis, modifying it a bit for our needs. The metadata is in the form <bug URL> <resolution>. Rather than editing existing commit messages, I just took that string and pasted it to the bottom of the commit message, but only if the bug number was not already in the commit message. This actually revealed a few typos in the “Bug 123456” strings that generally start commit messages.

There turned out to a few other subtle bugs, like the fact that a file which is both renamed and modified in the same commit shows up, in the output from bzr fast-export, as being modified under the original name. Thus if the delete is processed first, it looks like bzr has modified an nonexistent file. Those were easy to see by comparing the contents of every file before and after migration (admittedly just for the last revision).

Since there are a lot of branches on bzr.mozilla.org, I created a bash script to record them all and make sure none were missed. It output the pre-/postmigration diff of md5 sums as well as doing a git repack for each repo, after all branches were migrated.

One thing I forgot was pushing tags via the --tags option to git push; I had to do that manually after the migration. That’s also when I discovered that the same tag existed in several related bzr branches which were all combined into one git repo. This is, of course, not allowed in git. It made me think more about how Bugzilla uses certain tags, like current-stable, which are moved after each release. In git this requires the --force option to git push and is a big no-no if the remote repo is shared. I learned that, in fact, this is also the case in bzr, though perhaps it’s regarded as less of a sin than it is in git. Anyway, I’ve since realized that those should be branches, named appropriately (per branch). Despite them not being branches in the standard sense—they’ll always point to somewhere at or behind a version branch and never fork—it’s perfectly acceptable to move them, as opposed to tags, and since they’ll always be fast-forwarded, they won’t take any more space than a lightweight tag.

Mirroring

This was a harder problem. Originally, I tried to use the bzr-git extension, and it failed when I tried to pull in changes from git. I exchanged some emails with bzr-git’s author, Jelmer Vernooij, and he said that to keep an existing bzr branch in sync with a newly formed git repo is impossible at the moment: “This is essentially the ‘roundtripping’ support that we’ve been trying to achieve with bzr-git for a while. It’s a nontrivial problem (since it requires all semantics from bzr to be preserved when pushing to git).” Considering bzr-git hasn’t had a new release in two years, I won’t be holding my breath.

Luckily (and perhaps somewhat unfortunately) Bugzilla has jumped VCSes before, as I hinted above. With the old bzr-to-cvs script as a starting point, I created a git-to-bzr script—in, of course, Perl, as the original.

This script is essentially an automated way of applying individual commits from a git branch to a bzr branch. For each commit, the entire file tree is copied from a local git clone to a local bzr checkout, bzr add and remove are executed where needed, and the changes committed with the original author, contributor, and date preserved. The script also parses out the standard “Bug X:” commit-message format and passes it to bzr’s --fixes commit option. A file called .gitrev in the bzr repo tracks the associated git commit ID for each bzr commit.

To avoid excessive disk activity, since the script polls git and bzr for changes, the script uses bzr cat to check the contents of the .gitrev file and git ls-remote to get the ID of the last git commit. If they are equal, no further actions are performed.

Summing up

And that, folks, is how you can migrate from bzr to git! The initial migration is pretty straightforward, more so if you don’t care about any bzr commit metadata. It was unfortunate that there was no off-the-shelf way to sync the repos afterwards, but the basic idea isn’t too complicated.

For more, there’s the project page on our wiki, and all the scripts used are in a GitHub repo for your perusal. I’m no VCS expert—I’ve never heavily used bzr, and I’m constantly learning new things about git—but feel free to ask me questions if you want our process further clarified.

Vegan Bajan Tomato Sauce

| Comments

This isn’t a traditional recipe or anything, just something I put together one day. When we visit Barbados, we usually find a place with a kitchen, for various reasons: I like cooking, eating out every night is expensive (particularly in Barbados) and, now that I have a child with an early bedtime, getting out is a little tricky. But since we only stay for a week or two, buying all the spices I would normally use in tomato sauce is wasteful, and I never think to bring some with me. Hence one night my wife suggested using Bajan seasoning—a blend of shallots, garlic, hot peppers, and various herbs and spices. It’s a different taste, but quite delicious!

I use Delish Bajan seasoning, but I also found a recipe that I might try if I ever crave this recipe back home (although I will of course use a vegetarian Worcestershire sauce, such as The Wizard’s, athough it’s probably fine to leave it out, since I haven’t seen other recipes call for it). Bonus: that page has a recipe for hot sauce created by Barbados’s first Prime Minister, Errol Barrow!

The quantities below will serve about 3 people, but just double everything to serve 6.

  • olive oil
  • 1 small onion, chopped
  • 2-3 cloves of garlic, finely chopped
  • 5 fresh tomatoes, chopped according to preference (I like small dice)
  • 1 tbsp Bajan seasoning
  • 1 tsp salt
  • 1/3 package tofu

Optional:

  • 1 scotch bonnet pepper, finely chopped (or to taste—and I find the heat levels of fresh peppers can vary quite a bit here)
  • fresh or frozen spinach
  • black pepper
  • red wine
  • Bajan rum (for the chef, not the sauce)

Sauté the onion in the olive oil for a few minutes, until translucent. Add the garlic and sauté for another minute or so. Add tomatoes, Bajan seasoning, salt, and any optional ingredients. Mix well, bring to low boil, then reduce to a simmer. Cover pot and let cook for at least 15 minutes (longer is better, which gives a softer, velvety taste).

Meanwhile, steam the tofu. An easy way to do this is to put it in a bowl, add a teaspoon of water, cover, and microwave for 2-4 minutes (depending on your microwave). This dries out the tofu a little bit. You can also freeze and thaw tofu in advance for a similar effect. Fry it in some olive oil for 5 minutes or so, until it gets a bit chewy. I find (from vague recollection) that it can approximate the texture of ground beef. Add to sauce and mix well.

Serve over pasta of your choice.

BMO in 2013

| Comments

2013 was a pretty big year for BMO! I covered a bit in my last post on BMO, but I want to sum up just some of the things that the team accomplished in 2013 as well as to give you a preview of a few things to come.

We push updates to BMO generally on a weekly basis. The changelog for each push is posted to glob’s blog and linked to from Twitter (@globau) and from BMO’s discussion forum, mozilla.tools.bmo (available via mailing list, Google Group, and USENET).

I’m leaving comments open, but if you have something to discuss, please bring it to mozilla.tools.bmo.

Stats for 2013

BMO Usage:

35 190 new users registered
130 385 new bugs filed
107 884 bugs resolved

BMO Development:

115 code pushes
1 202 new bugs filed
1 062 bugs resolved

Native REST API

2013 saw a big investment in making Bugzilla a platform, not just a tool, for feature and defect tracking (and the other myriad things people use it for!). We completed a native RESTish API to complement the antiquated XMLRPC, JSONRPC, and JSONP interfaces. More importantly, we’ve built out this API to support more and more functionality, such as logging in with tokens, adding and updating flags, and querying the permissions layer.

Something worth taking note of is the bzAPI compatibility layer, which will be deployed in early Q1 of 2014. bzAPI is a nice application which implements a REST interface to Bugzilla through a combination of the legacy APIs, CSV renderings, and screen-scraped HTML. It is, however, essentially a proxy service to Bugzilla, so it has both limited functionality and poorer performance than a native API. With the new bzAPI compatibility layer, site admins will just have to change a URL to take advantage of the faster built-in REST API.

We are also planning to take the best ideas from the old APIs, bzAPI, the newly added functionality, and modern REST interfaces to produce an awesome version 2.0.

Project Kick-off Form

The Project Kick-off Form that was conceived and driven by Michael Coates was launched in January. The BMO team implemented the whole thing in the preceding months and did various improvements over the course of 2013.

The Form is now in the very capable hands of Winnie Aoieong. Winnie did a Project Kick-Off Refresher Brown Bag last month if you want, well, a refresher. We’ll be doing more to support this tool in 2014.

Sandstone Skin

BMO finally got a new default look this year. This was the result of some ideas from the “Bugzilla pretty” contest, the Mozilla Sandstone style guide, and our own research and intuition. BMO is still a far cry from a slick Web 2.x (or are we at 3.0 yet?) site, but it’s a small step towards it.

Oh and we have Gravatar support now!

User Profiles

Want to get some quick stats about a Bugzilla user—how long they’ve been using Bugzilla, the length of their review queue, or the areas in which they’ve been active? Click on a user’s name and select “Profile”, or go directly to your user profile page and enter a name or email into the search field.

File bugs under bugzilla.mozilla.org :: Extensions: UserProfile if there are other stats you think might be useful.

Review Suggestions and Reminders

Code reviews were a big topic at Mozilla in 2013. The BMO team implemented a couple related features:

  • Reviewer suggestions: When you are flagging a patch for review, you are now presented with a link to a list of one or more suggested reviewers according to the bug’s product and component. This is useful for new contributors who won’t necessarily know who would make a good candidate for review. Given beside the username is the number of reviews in that person’s queue, to encourage spreading reviews out.

  • Review notifications: As a result of a discussion on code reviews on dev.planning, by default you now get daily emails about your open reviews. You can also subscribe to these notifications for any Bugzilla user, something particularly useful to managers. As a bonus feature, you also get the number of requests assigned to you presented in a small red circle at the top of every Bugzilla page.

System Upgrade

When we upgraded† BMO to Bugzilla 4.2, IT also moved BMO from older hardware in Phoenix to new, faster hardware in SCL3. BMO was then set up anew in Phoenix and is now the failover location in case of an outage in SCL3.

† The BMO team regularly backports particularly useful patches from later upstream Bugzilla versions and trunk, but we fully upgraded to version 4.2 in the spring of 2013.

Other Stuff

We added user and product dashboards, implemented comment tagging, improved bug update times, and added redirects for GitHub pull-request reviews.

And then there were various bits of internal plumbing largely (by design!) invisible to users, such as the great tracking-flags migration; tonnes of little fixes here and there; and of course daily administration.

Plans for 2014

We’re already at work planning and implementing new features to start 2014 off right.

  • The Bugzilla Change Notification System will be deployed to production. This will allow external applications (and eventually the native UI) to subscribe to one or more bugs via Web Sockets and be notified when they change.

  • Performance instrumentation will be integrated into BMO (and upstream Bugzilla) to provide profiling data. Bugzilla’s been around for quite some time and, in supporting various complex workflows, its operations in turn can be quite involved. We’ll use data provided by this system to determine where we should focus optimization work.

  • We added memcached support to Bugzilla in Q4 of 2013; this will be pushed to BMO early in Q1 of 2014. Initially BMO will only use memcached for a few objects, but we’ll be adding more over time.

  • We’re setting up ElasticSearch clusters to provide a different way to access Bugzilla data, suitable for dashboards and general research.

  • Code reviews are a continued focus at Mozilla, so we’re implementing a way to get authoritative, comprehensive review data directly from BMO.

Our quarterly goals and other major work items are tracked on the BMO wiki page. You can also check out our road map for some vague ideas of plans into the future; these are ideas based on our current understanding of the Mozillaverse and will almost certainly change to some degree.

VMware Tools in Ubuntu

| Comments

I went about the seemingly simple task of sharing a directory in OS X with an Ubuntu VMware box so that I could code in my main desktop and run under Linux. The simple sharing dialog is of course only the beginning of the work; after that, I needed to refresh VMware tools, since I had done several kernel upgrades. Well that turned into a few hours of flailing at a command line.

For whatever reason, the kernel headers aren’t automatically found by the VMware Tools installation program, and even when you give the direct path, it still denies that they exist. Some web trawling told me that it looks for version.h, which isn’t in the root header directory, so I made a symlink. Then the installer found it but got compiler warnings a short time later.

I’m writing this post to tell you not to bother with any of that. Installing the open-vm-tools package from the multiverse repository is actually all you need! It’s amazing how many different searches it took for me to finally figure that out. I had to unshare and the reshare my directory for it to finally work, but now it’s working great. Let’s see what happens the next time I upgrade my kernel though…

ReviewBoard

There’s been a lot of interest in improving Mozilla’s code-review process lately, so in that vein the BMO team has set up a ReviewBoard instance at https://reviewboard.allizom.org for testing and evaluation.

ReviewBoard is a lot more useful than Splinter, so I suggest you try it out. One of the features I think will be most adored is proper interdiff support, made possible by the fact that ReviewBoard knows about the repo you’re working in. Tightly related is the ability to extend the context of the patch from the repo. Check out the ReviewBoard site for more.

Review apps, like most tools, are fairly contentious, so we wanted to give Mozillians a chance to try it out before we commit to it. Other options, like Phabricator, have been suggested; we happened to have been working on ReviewBoard. I’d like to hear from the greater public before settling on one for at least a few years.

For this experimentation phase, we’ve only done minimal integration with Bugzilla, namely, having ReviewBoard use Bugzilla’s accounts. You log into ReviewBoard with your Bugzilla account, and ReviewBoard’s username autosuggest is linked to Bugzilla (similarly, reviewboard-dev uses bugzilla-dev’s user database). (Note that this version of ReviewBoard doesn’t support Persona, but it should be there soon.) There’s a lot more we could do; some examples are in bug 515210. Again I’d like to hear feedback in order to prioritize our work.

I suggest using ReviewBoard much like we use GitHub pull requests. Start a review, then paste the URL as an attachment on a Bugzilla bug. Bug 922226 is on file to get redirects working for ReviewBoard reviews the way they do for pull requests.

For now, please don’t use ReviewBoard for any non-public (e.g. security-related) or really critical reviews. While the security team has gone over ReviewBoard, we’re still considering this an evaluation phase. We’ll also have to put some work into ensuring that only the right people can see non-public reviews; Bugzilla’s security system is rather fine-grained and complicated, so this will take some thought and possibly some modifications to ReviewBoard itself (don’t worry, we have several ReviewBoard developers in house!).

Finally, to get your repo added—having a linked repo is where you really see the value of ReviewBoard—either file a bug or drop by #bmo on IRC.

Please direct all feedback to mozilla.tools.bmo. To reinforce that, I’ve disabled comments on this post.

Mid-August BMO News

| Comments

A lot of people probably don’t know that I manage the team behind BMO, that is, bugzilla.mozilla.org, Mozilla’s Bugzilla installation. Work on BMO is continuous and incremental, and even really useful features often take a while to percolate through the community, so I thought I’d try to draw attention to some recent improvements that should get you pumped to open a Bugzilla tab.

Suggested Reviewers

A really exciting, and long-awaited, feature is suggested reviewers. Now when you flag a patch for review, you see a list of people who should make good candidates. And as of today, you can even see the number of reviews in each person’s queue! There is a lot more in this feature, with even more to come, so I’ll just run down a list:

  • The set of reviewers is per Product and per Component. If there are reviewers set for the particular Component, they are used; otherwise, it defaults to that Product’s reviewer set.
  • The full set is available as a report within Bugzilla. Anyone with “editcomponents” permission on a Product can change reviewers for that Product or its Components. Changes can also be requested by filing a bug or dropping by #bteam and talking directly to glob or dkl.
  • The order of the suggested reviewers is identical to how it appears in the report, which can be modified as above.
  • Anyone with “away”, “PTO”, or “unavailable” in their “real name” field will not be listed.
  • Any bug that has a mentor set ([mentor=X] in the whiteboard) will automatically have that user included in the suggested reviewers, at the top, in bold, since presumably that person is best suited for this particular bug.

Coming down the pipe is the ability to assign reviewers to subcategories of a particular component, which will show up beside the reviewer’s name in the list. Thus for components like Mochitest, you could indicate that a reviewer is particularly suited to b2g-specific parts of the framework. This avoids having to create tonnes of smaller components just for reviewing purposes.

Gravatars and the Sandstone Skin

There is now an option to display Gravatars beside comment headers. As with any Gravatar-enabled site, the avatar is displayed if the commenter’s bugmail address has an associated Gravatar. At the moment it is opt-in, enabled from the Preferences page (General Preferences / Show gravatar images when viewing bugs), but when the Sandstone skin becomes the default, Gravatars will be enabled for all users—but of course you can opt out if you really don’t like them.

Speaking of the Sandstone skin, some more improvements to it have landed recently. It’s pretty slick, in my opinion, and will become the default skin in a week or two when a couple remaining issues are resolved. For now, you can try it out by setting the General Preferences / Bugzilla’s general appearance (skin) option to Mozilla. Of course, after it is made the default, you can switch back to the old default (Dusk) if you prefer.

We have some more awesome changes landing in the next few weeks; I’ll post another summary then.