Category Archives: Bugzilla

Old Requests: Next Steps

Posted on by
18

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
6

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.

BMO Upgraded to 4.0

Posted on by
1

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
2

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
1

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
7

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
Reply

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)

bugzilla.mozilla.org: Status Field Changes

Posted on by
11

Update: this is sadly not as easy technically as it should be (e.g. Bugzilla 3.6 has several hard-coded status names lurking in the code). This is definitely not happening on Tuesday, and may have to wait until we upgrade to 4.0. <sigh>.

Next Tuesday, 9th November When we upgrade to Bugzilla 4.0, the values of the Status field in bugzilla.mozilla.org are changing, as discussed in mozilla.dev.planning. This is to match us up with upstream changes, make it more clear what each state means, and to clarify which bugs are the responsibility of QA and which of Dev.

The changes are as follows:

  • NEW will be rename to CONFIRMED, so all existing bugs change
  • ASSIGNED will be renamed to IN_PROGRESS, ditto
  • READY_TO_FIX is a new state (see below)
  • REOPENED will be removed (reopened bugs go straight to CONFIRMED or IN_PROGRESS)

So the Statuses and their meanings will be as follows:

Status Meaning Responsible
UNCONFIRMED not confirmed; filed by inexperienced reporter QA
CONFIRMED can reproduce, not an obvious dupe QA
READY_TO_FIX has appropriate QA/UX work complete, ready for a developer Dev
IN_PROGRESS developer is working on a patch Dev
RESOLVED patch has been committed to trunk QA
VERIFIED fix has been QAed in builds n/a

Bugzilla 600,000 Bug Sweepstake Results

Posted on by
3

Milestone bugzilla.mozilla.org bug 600,000 was filed on 2010-09-27 at 13:44 ZST by Frank Wein (mcsmurf).

The winner of the sweepstake to guess the date and time is Karsten Düsterloh, who guessed 2010-10-07 20:00:00 – 10 days, 6 hours and 16 minutes out. Accuracy is still decreasing over the years; it looks like this is geting harder to predict. Most entrants thought it would take longer than it did to get here.

Karsten writes:

I’m a SeaMonkey developer and author of the Mnenhy extension. I got drawn into Mozilla with milestone Msomething last century and even dared to file a five digit dupe a while later. MailNews development was slow even back then, so I started my own add-on in late 2002 – and it’s still alive!

My current focus is upon SeaMonkey MailNews and the future of open internet communication.

Karsten wins a Firefox backpack. The two runners-up are Dave Garrett (12d 20h 26m out) and Wladimir Palant (14d 20h 07m out) – in Wladimir’s case, for the second year running. They both win their choice of a t-shirt from the Mozilla store. Dave writes:

I got drawn into the Mozilla world in 2007 and it somehow went from filing a few bugs and improving an extension to testing and triaging Firefox and AMO bugs and being the developer of the Flagfox extension with over a million users. I’m not quite sure how that happened.

Wladimir writes:

I got involved with Mozilla in 2003 shortly after switching to Mozilla Suite – playing around with add-ons was just natural, it didn’t take long for me to start fixing issues in the ones I used. Soon I was writing my own extensions and eventually ended up creating Adblock Plus which turned into a very time-consuming hobby.

Bugzilla API 0.6.1 Released

Posted on by
Reply

Version 0.6.1 of the Bugzilla REST API has been released, and the main api-dev server should be back up and working fine. If it’s not, let me know.

New In 0.6.1

  • Compatibility with Bugzilla 3.6. If you are using the 0.6 version
    against bugzilla.mozilla.org or another installation of Bugzilla 3.6,
    upgrade, because some of your calls may no longer work.

Compatibility Notes

  • Two things are still not working: JSONP, and the new_since parameter to the /comments call.
  • Version 0.5 is now no longer available on the api-dev server.

File bugs | Feedback and discussion

1000 Reported Bugzilla Installations

Posted on by
1

I just added the 1000th entry to the Bugzilla Installation List. Almost all of that list (a few were originally found by web trawling) is made up of companies who took the time to get in touch with us and thank us for writing Bugzilla. Which is really encouraging. :-)

I prune the list every few months to remove dead links and defunct companies, but of course we can’t tell if a company stops using Bugzilla and doesn’t tell us. Then again, Max tells me that, from update pings, he can tell that there are at least ten times that number of active installations out there. So the figures have uncertainty in both directions.

Still, it’s a pretty cool milestone.

Bugzilla API 0.6 Released

Posted on by
Reply

Version 0.6 of the Bugzilla REST API has been released.

New In 0.6

  • Include and exclude fields support, so you can define exactly what data you want each call to return;
  • Cookie auth – if you have access to a user’s existing Bugzilla login cookie information, you can use that instead of prompting them for a username and password;
  • Performance improvements for /configuration call, with recent Bugzillas (not yet available on bugzilla.mozilla.org);
  • Addition of comments with attachment updates now works properly.

Compatibility Notes

  • Some of the previous methods of including and excluding specific fields no longer work, although “attachmentdata=1” is still supported as a shorthand;
  • Versions 0.4.1 and below had a security issue[0] which could, under some circumstances, allow one user to impersonate another. These versions are now disabled on the server, and the bug has been opened.

File bugs | Feedback and discussion