Category Archives: Bugzilla

Bugzilla API 1.3 Released

Posted on by

I am proud to announce the release of version 1.3 of the Bugzilla REST API. This maintenance release has a bug fix or two, and fully supports the version of Bugzilla 4.2 which has just been deployed on bugzilla.mozilla.org. For smooth interaction with BMO, you should be using this version.

The installation of BzAPI 1.1 on api-dev.bugzilla.mozilla.org will go away in 4 weeks, on 4th April. There is a limit to the number of old versions we can support on the server, particularly as the older ones can put a larger load on Bugzilla and may not work correctly. Please use either the /1.3 or the /latest endpoints. Now that BzAPI has been stable for some time, tools which earlier rejected using the /latest endpoint may want to reconsider.

File bugs | Feedback and discussion

Persona Login Now Fully Enabled On bugzilla.mozilla.org

Posted on by

[Update 2013-01-23 18:35 GMT - turns out there are a couple of Persona features we still need to be absolutely certain that this is a good thing. The change has been reverted until we've got those. Sorry for any confusion.]

In April last year, we enabled Persona logins on bugzilla.mozilla.org using a Bugzilla extension I wrote. However, we restricted this login method to low-privilege accounts only while Persona and the extension both matured.

I’m pleased to say that, as of now, unless you are a member of the administrative Bugzilla groups “admin”, “editusers” or “editgroups”, or the “legal” group, then you can now use Persona to log in to bugzilla.mozilla.org :-) In particular, this means all Mozilla employees and security group members can now log in this way.

Make sure you use the correct email address; if you pick a different one to your usual one, Bugzilla will auto-create a Bugzilla account for it.

If for some reason you want b.m.o. not to accept Persona logins for your account, you can do so; file a bug to have your account manually added back to the “no-browser-id” group.

Bugzilla API 1.2 Released

Posted on by

I am proud to announce the release of version 1.2 of the Bugzilla REST API. This maintenance release has a bug fix or two, and some features useful to the admins of Bugzillas which BzAPI is pointed at.

The installation of BzAPI 1.0 on api-dev.bugzilla.mozilla.org will go away in 4 weeks, on 19th December. There is a limit to the number of old versions we can support on the server, particularly as the older ones can put a larger load on Bugzilla. Please use either the /1.2 or the /latest endpoints. Now that BzAPI has been stable for some time, tools which earlier rejected using the /latest endpoint may want to reconsider.

File bugs | Feedback and discussion

bugzilla.mozilla.org Now Supports BrowserID

Posted on by

You can now log in to bugzilla.mozilla.org using BrowserID, courtesy of a Bugzilla extension I wrote. Log out and then click the “Login” link in the header and then the orange “Sign in” button to try it.

You can do this – unless, that is, you are a member of certain particularly sensitive groups. While Mozilla has great confidence in the BrowserID technology, it does not have perfect confidence in my coding ;-) Therefore, we are restricting who can log in until we get a little more experience with my extension. Eventually, it’s possible that we might go the other way and require BrowserID for certain sensitive groups, once BrowserID primaries appear with 2-factor authentication. But that’s a little way off yet.

If you visit your permissions page, you can see if you should be able to log in using BrowserID. If you are listed as a member of the “no-browser-id” group, you shouldn’t. Otherwise, you should. The no-browser-id group is currently made up of members of the following groups: admin, bz_sudoers, autoland, generic-assignees, hr, infrasec, legal, and anything with “security” in its name.

Maintaining Multiple Versions of Documentation in a Wiki

Posted on by

Dear Lazyweb,

I know of some software, and it has documentation. I want to be able to maintain this documentation, for the general good of its userbase. At the moment, its documentation is XML files in a VCS, with their own special build procedure with prerequisites. That makes them hard to modify, and as a consequence they are often out of date and certainly not as good as they could be.

Requirement A): I’d like the documentation to be web-editable, because that makes it really easy for anyone to edit quickly, which makes it much more likely the documentation will actually be up-to-date. I want the URL for the “latest version” to always be the same URL.

Requirement B): My software has multiple versions. Once I release a version, I’d like to keep a copy of the documentation in the state that it applies to that version. It may not change much again, but needs to be able to accept bug fixes. However, trunk documentation development must continue. In other words, I need to be able to branch the documentation, check in independently to each branch, and give people URLs to either a branch or the trunk. Each version should have a URL containing the software version number.

Is there any software out there, ideally already in use by the Mozilla project, which can meet both A) and B)? A) is met by all wiki software. B) is met by all version control software. But I haven’t found wiki software with the concept of branches, and I haven’t found a VCS which can display documents prettily and has a web-based interface for editing.

These requirements don’t seem uncommon. Proprietary software solves them. Is there anything open source?

Old Requests: Next Steps

Posted on by

You may recall we are doing some work to try and clear the backlog of old requests (review, super-review, feedback etc.) This first involved sticking a CSV template on bugzilla.mozilla.org so we could monitor the number and age of outstanding requests. Since mid-December, I’ve been downloading a full dump of the outstanding reviews each day. Then, in mid-January, we implemented a gently nagging email, to be sent every week, reminding people about their requests older then 7 days. I have now written a script to analyse that data, to see if the email has had any effect.

Here’s what happened, looking at the most common type of request (“review”), in terms of the number of review-days outstanding[0]:

The first noticeable downtick in the graph is just after the first nagging email got sent out, and as you can see, the effect continued weekly for about a month, before vanishing, and the level plateaued again. I would interpret that as an indication that all the low-hanging fruit is now gone. And there’s still a lot of outstanding reviews – 928 older than 90 days (down from 1192).

We reduced the number of outstanding review-days. But was this due to people dealing with some old ones, or were people getting more timely with newer ones? If we do the graph again, this time ignoring all reviews older then 30 days, we can see that (if we assume the number of new review requests per day is roughly constant, which as far as I can tell it is) there’s not been much reduction in waiting time:

So what do we do now?

I think we want to get to a place where no request is outstanding more than 30 days, and where someone with contributor engagement can monitor requests as they cross that threshold and try and see why and when something went wrong. On average, 4.4 reviews a day cross the 30 -> 31 day threshold. As reviews are the most common type of request, I’d suspect it’s about 5 requests a day.

Here are some options to clarify the situation and make it better in the future (of which we could do more than one). Note that here I am talking about requests which have the ability to take an explicit requestee (such as “review”).

  1. Ban new requests “of the wind” (ones without a named requestee)
  2. Ban new requests of requestees who have not been active in Bugzilla for > N days (suggested N: 30)
  3. Cancel existing requests of requestees who have not been active in Bugzilla for > N days (suggested N: 30)
  4. Cancel existing requests on VERIFIED bugs (are there any which could validly be on such bugs?)
  5. Cancel existing requests on RESOLVED bugs (are there any which could validly be on such bugs?)
  6. Cancel existing requests which have been outstanding > N days (suggested N: 30)
  7. Find someone to examine requests which cross an N-day boundary and investigate them (suggested N: 30)

All bans would be accompanied by advice on finding an appropriate reviewer. All cancellations would be accompanied by an apologetic comment and useful advice for the patch submitter about steps to take next.

Thoughts?

[0] Note: I’m no statistician. I’m happy to give my collected data to anyone else who wants to do some analysis. Just email me. Anyone who wants a CSV dump of all current requests, it’s here.

Bugzilla 700,000 Bug Sweepstake

Posted on by

It’s that time again! :-) The bugzilla.mozilla.org bug database will soon hit another major milestone and again, as is traditional, I’m running a sweepstake on exactly when that will be. Although you should enter just FTW, we are also giving Mozilla gear as prizes – a backpack for the winner, and a t-shirt for 2nd and 3rd.

So please email me using this link, filling in the date and time you think bug 700,000 will be filed. As the link suggests, your entry should be on the first line of your email, and formatted as follows:

2010-09-08 06:54:32 bugzilla-id@example.com

All times are in ZST (‘Zilla Standard Time, a.k.a. Pacific Time, as displayed in Bugzilla timestamps unless you’ve changed a pref), and the email address must be your Bugzilla ID. If you prefer to be contacted on a different address, add that as well, on the end of the same line in brackets. We have ample graphs and charts (requires editbugs) to help you with your assessment. But if you can’t be bothered to do any research and analysis, just guess optimistically and hope!

This is a Mozilla community event. To keep it that way, entrants must have a Bugzilla account on bugzilla.mozilla.org created before the end of July 2011, and which has done something useful in the past six months. I’ll check those who are closest, and keep discarding entries until I find one which meets these criteria. Therefore, there’s no point posting this to Slashdot or any other non-Mozilla-focussed news source.

The judge’s decision is final, and any funny business regarding the filing of bugs on or around the 700,000 mark will be frowned upon. The closing date for entries is midday ZST on Wednesday 31st August 2011.

bugzilla.mozilla.org Metrics

Posted on by

Some interesting metrics relating to bugzilla.mozilla.org, courtesy of justdave:

Metric Ever Last 30 Days
Logged In Users 414,284 7,153
Users Who Changed A Bug 4,053
Bug Reports 654,360 6,939
Unique Bug Reporters 144,950 2,126
Unique Attachment Uploaders 29,427
Unique Patch Submitters 5,265 370
Unique Commenters 180,927 3,616
Comments 5,446,473 57,182

BMO Upgraded to 4.0

Posted on by

As many of you will have noticed, bugzilla.mozilla.org has been upgraded to Bugzilla 4.0. This upgrade brings many new features, but also a number of extensions implementing long-desired capabilities:

  • Splinter – Review Board-style code review
  • Component Watching
  • SecureMail – encrypted bugmail for security bugs

One caveat: don’t go converting all of your generic-QA-contact-watching to Component Watching just yet, because it doesn’t respect email preferences yet and so you will be deluged with “CC” mail.

We plan to roll out SecureMail group by group, starting with a small group (my suggestion is to begin with the Bugzilla software security group). However, following a suggestion from justdave, once my patch is checked in anyone will be able to protect their password reset mail just by adding a private key to their SecureMail preferences.

Please continue to file bugs on any issues you find – here’s the tracking bug.

Bugzilla API 0.9 Released – INCOMPATIBLE CHANGES

Posted on by

Version 0.9 of the Bugzilla REST API has been released.

This version has INCOMPATIBLE CHANGES in the data format – some field and parameter names have changed (see below). Therefore, the “/latest” installation on https://api-dev.bugzilla.mozilla.org has not been updated with it yet. It will be updated on


Wednesday 2nd March

which is 1 month from today. At that point, all clients using that installation must be able to deal with both old and new formats.[0] If you want to only support one format, you can update your code and migrate to the /0.9 installation at any point before then.

Also, 0.9 fixes BzAPI to deal with some late-breaking Bugzilla 4.0 changes. If you are deploying Bugzilla 4.0, this is the version you will need.

People deploying installations of 0.9 against their own Bugzillas should take note of the “Upgrading” section below.

New In 0.9

  • Field name changes to match XML-RPC API
  • Bugzilla 4.0rc2 now fully supported

Compatibility Notes

  • Four field names on the “Bug” object have changed, to match the names chosen for the Bugzilla XML-RPC API’:
    • reporter -> creator
    • is_reporter_accessible -> is_creator_accessible
    • token -> update_token
    • is_everconfirmed -> is_confirmed

    In each case, you will need to change your code to look for the first hash value and, if it’s not found, look for the second one.

  • The emailN_reporter field is now called emailN_creator, to match the
    above change.

  • Versions 0.6.1 and 0.7 are now no longer available on the api-dev
    server.

Upgrading Your BzAPI

BzAPI now comes with a Bugzilla extension, suitable for 3.6 and above, which replaces (most of) the patches that we used to ship. Unless you are on an earlier version of Bugzilla, please remove the old patches (except the XML-RPC one) and install the extension instead. You may want to symlink it so it automatically gets updated in step when you upgrade BzAPI.

Those choosing not to do this will still need to take a new version of config.json.tmpl from the patches/ directory.

File bugs | Feedback and discussion

[0] I apologise for not having a better backwards-compatibility story, but it was very difficult to update all the tests to support the data being duplicated in two field names. I tried, and gave up as it was taking too long. And this is pre-1.0 software (just).

Time Tracking in bugzilla.mozilla.org

Posted on by

Recently, two groups (one from Adobe and one from Mozilla Mobile) have asked for better facilities to track people’s work time on bugzilla.mozilla.org. Bugzilla does have a time-tracking function; however, it is quite UI-heavy, so we did not want to enable it globally. Bugzilla’s UI is already complex enough :-)

So, we have decided to enable it only for members of a particular group, the “timetrackers” group. People at Adobe and members of the Fennec team are automatically members, but no-one else is. In this way, we keep the extra UI complexity contained to those who want it.

However, we don’t want Bugzilla to contain information not accessible to the community (other than by specific policy, such as our security policy, or company-internal information). So we want to make it clear that anyone with the “editbugs” privilege can ask to be made a member of the “timetrackers” Bugzilla group, without needing to give a reason. Then, they can get the extra time-tracking UI on all bug views, and see what the Tamarin and Mobile teams are doing with it. We don’t expect many people to want to do this, but we think it’s important that it’s possible :-)

Profanivore – A Bugzilla Extension Which Eats Bad Words

Posted on by

Recently, an unusually persistent troll came into Bugzilla and started swearing at contributors. This was obviously an unpleasant experience for them, and led me to thinking how we can balance Mozilla’s desire to be a place where everyone is welcome (some of our most awesome contributors have started when under 16, for example) and yet we support the general principle of freedom of speech (which is most important in government-related censorship contexts, but is also important in general).

So a couple of weeks ago I wrote Profanivore, a Bugzilla extension which ‘eats’ English profanities in Bugzilla comments, leaving behind instead a trail of droppings (‘****’). The profanity is only eaten where the comment was written by a user who does not have the global ‘editbugs’ privilege. The digestion happens at display time, so the comment in the database is unaltered.

I wrote this very carefully to walk the line between being over-censorious and being protective of our users having to read abuse from trolls. Hence the “you can swear if you have editbugs” feature.

Unless this meets with serious objections, we plan to enable it on bugzilla.mozilla.org some time in the reasonably near future. If we do, please resist the temptation to test it. It uses a standard Perl module for detection so I have reasonable confidence it’ll do the right thing most of the time, but do let me know if it censors your Scunthorpe.

Bugzilla API 0.8 Released

Posted on by

Version 0.8 of the Bugzilla REST API has been released.

People deploying installations of 0.8 against their own Bugzillas should take note of the “Upgrading” section below.

New In 0.8

  • Use quicksearch syntax on the /bug search call with the parameter “quicksearch=“.
  • Non-ASCII bug data now works in more places (hopefully everywhere)
  • /configuration data is now cached and you can asked for the cached version if performance is more important to you than freshness; see

    https://wiki.mozilla.org/Bugzilla:REST_API:Methods#Configuration_.28.2Fconfiguration_GET.29

  • Bugzilla 4.0rc1 now fully supported

Compatibility Notes

  • “is_url” support for attachments has been removed from Bugzilla, and so from BzAPI (including against older versions of Bugzilla). BzAPI will emulate the backwards-compatibility behaviour of new Bugzillas when it encounters attachments which are URLs.
  • On the Comment object, “author” is now “creator”, to match a change made in the Bugzilla XML-RPC API for version 4.0.
  • Versions 0.6.1 is now no longer available on the api-dev server.

Upgrading Your BzAPI

BzAPI now comes with the patches necessary to install it, in the /patches subdirectory.

Those upgrading from pre-0.8 to 0.8 will need to:

  • Update their Bugzilla to the latest point release of their stable
    branch

  • Update their copy of $BUGZILLA_HOME/template/en/default/config.json.tmpl from that in the /patches directory
  • Apply a patch (xmlrpc-fix.diff) to their copy of BZ::Client’s Client.pm if they want bug submission with non-ASCII values for e.g. summary to work.

(File bugs | Feedback and discussion)