Category Archives: Bugzilla

bugzilla.mozilla.org: Status Field Changes

Posted on by

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

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

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

BzAPI Unwell

Posted on by

Some parts of the bugzilla.mozilla.org BzAPI are a little unwell at the moment, following the upgrade to 3.6. I have fixes in hand, and hope to ship a new, working version tomorrow.

1000 Reported Bugzilla Installations

Posted on by

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

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

Bugzilla API 0.5 Released

Posted on by

I noticed I forgot to blog this…

Version 0.5 of the Bugzilla REST API has been released.

Note: versions 0.4.1 and below have a security issue[0] which could, under some circumstances, allow one user to impersonate another. If you are specifically using these versions (rather than the “latest” version) please update your client software to use version 0.5.

New In 0.5:

  • Performance instrumentation. I have added code which records how long requests take, so I can see whether the bottlenecks are, if any. If you are having performance issues with the API, please file bugs and tell me what is slow!
  • JSONP support. Use Accept: application/javascript and pass a callback=myfunction parameter, and you will get JSONP served as application/javascript.

Compatibility Notes:

  • The range of content types that the API can return is now restricted
    to:

    • YAML-HTML (for browsing) – text/html
    • JSON – application/json
    • JSONP – application/javascript
    • XML (utterly unfrozen!) – application/xml
  • The deprecated “count=1″ parameter to bug searches to get a count has been removed.

File bugs | Feedback and discussion

[0] This bug will be opened in a few days.

Community Size, and Bug Quality

Posted on by

I’ve just finished watching Diederik van Liere’s fascinating presentation (Ogg video, 20 mins), linked to by Mark, about his work with bugzilla.mozilla.org data. Download the full slide deck – you’ll need it to follow along with my comments, which should be of interest to the community-minded.

Slides 9 and 10, the community dynamics slides, are worrying. Diederik explains the decline in the size of the community as “increased product maturity”, but I’m not sure that’s true. If it were, we would expect to see the number of people entering the community decreasing. However, that number has stayed roughly constant, with peaks surrounding a release as we reach out to beta testers, and as new users report bugs. It’s the number of people leaving which seems to be increasing. Fewer people are hanging around once they get here. And I don’t know why.

Slide 11, about what the final resolutions ended up being of bugs filed in each year, is fascinating. It would be really interesting to see that graphed at a greater granularity.

We have made significant progress in reducing the percentage of duplicate bugs filed. People complain about Bugzilla’s search, but the percentage was a flat 25% from 2002-2004, and it’s now a flat 13% – basically half what it was. Also, from a low of 34% of bugs filed being FIXED, we are now up at 56%.

There are no doubt lots of factors involved in this effect, including the reduction in the size of the community mentioned in the earlier slides. I’m really interested in working out what we might have done which has improved the situation. I have an utterly open mind on this. here are some significant events I can think of which may be relevant:

Can anyone else think of other events or software deployments which may be relevant? I’m happy to do the research to find out when they happened.

From The Wind

Posted on by

It’s not possible to search Bugzilla for bugs where a particular flag has been set with no requestee. This means that people sometimes request e.g. review “from the wind” (as bugbot puts it) and no-one notices, so their patch sits there for ages, unloved.

Here is a Greasemonkey userscript which adds a “From the Wind” button at the bottom of buglist pages on bugzilla.mozilla.org. Clicking that button (after a few seconds) trims the list down to only those bugs where “review” (on an attachment) or “approval” has been requested from the wind. (It does this by fetching the bug data from the API and doing the check itself.)

So if you search for all bugs in the relevant component or product with “review?”, and then click the button, it’ll trim that list down to all bugs with “review?” and no requestee.

Why not take a moment to do this in a product or component for which you have review responsibilities?

Why didn’t I use Jetpack? Because at the moment (Firefox 3.6b4, Jetpack 0.7) the authoring experience is really not good. The API documentation doesn’t even mention that it uses jQuery (which led to me thinking for a long time that it was missing huge chunks of function), the Bespin code window is way too small and non-resizable, using Ctrl-X/C/V cut-copy-paste scrolls the page to the top, errors appear in the Firebug on the Jetpack page rather than the web page itself, you have to keep clicking “Try out this code” and “clear” on the Firebug on both pages, and I can’t see how to step through the code using the debugger.

Bugzilla API 0.4 Released

Posted on by

Version 0.4 of the Bugzilla REST API has been released. New in this version:

  • New /count call – get fast bug counts, either singly or in 1D, 2D or 3D tables. Great for stats.

Compatibility Notes:

  • The “count=1″ parameter to bug searches to get a count is now deprecated, and will be removed in a future release. Use the above API call instead.
  • The Configuration object’s “groups” hash will soon change to be keyed by ID rather than name (and so the “id” field has disappeared, to be replaced by a “name” field). Tracking bug.

File bugs | Give feedback.

Bugzilla API 0.3 Released

Posted on by

Version 0.3 of the Bugzilla REST API has been released. New in this version:

  • name=value search for arbitrary fields; e.g “&cf_mycustomfield=somevalue”
  • All timestamps are now in UTC, ISO 8601 format
  • Support for OPTIONS
  • Access-Control-Allow-Origin header now on all responses (permits cross-site requests)
  • Support for downloading bug data for multiple bugs, in full, in a single request (see docs for search to find out how)
  • Text searches now default to “contains_all” (as substrings, space-sep)
  • Initial support for decent error codes – however, don’t rely on them not changing!

Compatibility Notes:

  • Note that the timestamps format change is backwardly-incompatible.
  • All API capabilities now work against bugzilla.mozilla.org, now that it’s been upgraded and patched.
  • An advance warning: in the next release, the Configuration object’s “groups” hash will change to be keyed by ID rather than name (and so also the “id” field will disappear to be replaced by a “name” field).

File bugs | Feedback and discussion.

Bugzilla API 0.2 Released

Posted on by

Version 0.2 of the Bugzilla REST API has been released. New in this version:

  • Read/write support for flags, groups, custom fields and comment privacy
  • Access to all aspects of Bugzilla’s configuration with a new /configuration call
  • Even more high-quality and comprehensive documentation
  • Better logging so I can debug problems

Note that these new capabilities will not be available on the copy of the API pointed at bugzilla.mozilla.org until the upgrade :-( But in the mean time, you can test them on the staging server. Although that seems very slow at the moment.

I consider this the first version of the API with which you should be able to write a capable Bugzilla client of some sort. Let me know if you find stuff missing which would be required for this usage.

Lastly, there is now a Bugzilla component for you to file bugs in :-)