Have you written an app or system of some sort which uses the Bugzilla REST API (BzAPI)? If so, please do as the docs have long recommended and make sure you are a member of the mozilla.tools discussion forum. There are several upcoming announcements in the next few weeks and months which you will need to be aware of, and that is where they are going to be posted.
[Note: The closing date for entries was midday ZST on Thursday 5th September 2013, i.e. a long time ago :-).]
Some of you may have noticed that, after a long history of contests, there was no competition to predict the time of arrival of the 900,000th bug on bugzilla.mozilla.org. This was because we were preparing for the big 1M.
Now we are over 9000,00 (can that really be right?), I can reveal that the prize for the Millionth Bug Sweepstake will be the top-of-the-range Most Splendid Package from the Mozilla Gear Store, which includes a black hoodie, a drawstring tote bag, a Moleskine notebook, and a Rickshaw laptop bag, all Firefox or Mozilla-branded.
The aim of the contest is simple – you need your guess to be the closest to the actual filing date of the one millionth bug in our Bugzilla installation.
To enter, email me a plain text email at email@example.com, ideally using this link, filling in the date and time you think the one millionth bug will be filed, along with your Bugzilla ID or email address. 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 firstname.lastname@example.org
All times are in ZST (‘Zilla Standard Time, a.k.a. Pacific Time, as displayed in Bugzilla timestamps unless you’ve changed a pref). If you prefer to be contacted on a different address, add that as well, in brackets on the end of the same line. 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 either a Bugzilla account on bugzilla.mozilla.org created before the end of July 2013, and which has done something useful in the past six months, or a Mozillians account vouched for before the same date. Anyone who meets those criteria can (and is encouraged to) enter, including Mozilla employees. Once the bug is filed, I’ll check those entries who are closest, and keep discarding them 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. But please do post it in Mozilla news sources!
Badly-formatted entries may be discarded. The judge’s decision is final, and any funny business regarding the filing of bugs on or around the one million mark will be frowned upon. The closing date for entries is midday ZST on Thursday 5th September 2013.
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.
[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.
BMO is a core tool in the Mozilla project. There is now a shared, curated space for people’s tips, ideas, best practices, FAQs and so on relating specifically to BMO: https://wiki.mozilla.org/BMO/Support.
Suggestions for additional content would be very welcome.
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.
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.
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?
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:
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”).
- Ban new requests “of the wind” (ones without a named requestee)
- Ban new requests of requestees who have not been active in Bugzilla for > N days (suggested N: 30)
- Cancel existing requests of requestees who have not been active in Bugzilla for > N days (suggested N: 30)
- Cancel existing requests on VERIFIED bugs (are there any which could validly be on such bugs?)
- Cancel existing requests on RESOLVED bugs (are there any which could validly be on such bugs?)
- Cancel existing requests which have been outstanding > N days (suggested N: 30)
- 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.
 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.
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 email@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.
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|
|Unique Bug Reporters||144,950||2,126|
|Unique Attachment Uploaders||29,427|
|Unique Patch Submitters||5,265||370|
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.
A reminder – one week from today, the copy of BzAPI at https://api-dev.bugzilla.mozilla.org/latest will be upgraded and there are incompatible changes. Please prepare your clients.
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. 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
- 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
- Versions 0.6.1 and 0.7 are now no longer available on the api-dev
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.
 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).
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 :-)