html bugmail comes to bugzilla.mozilla.org

due to unforeseen delays in upgrading bmo to bugzilla version 4.2, we’ve back-ported and deployed html bugmail!

during our evaluation of bugzilla 4.2 it became clear that a feature of searching in 4.0 was not implemented when the searching backend was rewritten for 4.2. (bug 677757)

bmo isn’t running a standard version of bugzilla 4.0 — we have a large number of bugzilla extensions installed to provide a host of extended functionality, and we’ve also backported a lot of features and fixes from 4.2 and 4.4. when it became clear the issue with searching would delay the upgrade, we discussed at length which features in 4.2 we’re missing and the viability of backporting the features to 4.0. by and far the feature which garnered the most positive comments and feedback was html bugmail, and the decision was made to backport.

while i’ve been working on search, dkl took on the task of the backport (bug 775275), and we’ll be making those changes live today.

the initial default format for bugmail will continue to be text-only, use preferences to change to your preferred email format to html for a sneak peek.

we will change the default format for all users from text to html in approx 3 weeks.

if you run a system which parses bmo’s bugmail you may see minor differences in the text mail. if your system doesn’t support multi-part or html content you should login to bmo and change your account’s preference from ‘site default’ to ‘text only’.

edit: we’ve temporarily disabled html email while we investigate an intermittent problem with blank bugmail (bug 785308)

8 thoughts on “html bugmail comes to bugzilla.mozilla.org

  1. Is there a way to get more advance notice of changes to the bugmail format? I have a bugmail scraper that is now failing on a bunch of bugmail 😦

    • this /is/ the advanced notice; we’ll be making the real change in 3 weeks times. there should have been minimal changes to the text only format today.

      bugmail isn’t a stable api for bugzilla, so if you’re scraping the content you can expect these sorts of changes from time to time. i don’t think it’s reasonable to expect advanced notice on every minor change to bugmail.

      that said, i’m interested in what changes to the text only bugmail broke your scraper.

      • It looks like the main change that caused breakages was the change in the X-Bugzilla-Changed-Fields header. It used to report the same field names as appear in the body of the email (in the ASCII art tables) but now it reports what look like table column names from the bugzilla DB schema. This makes parsing the ASCII table a bit harder because now I need to keep a map of column names to ASCII table names.

        FWIW, a lot of people have a love-hate relationship with bugmail today; it’s an integral part of their workflow, but the volume of it is so high that dealing with it in email form is excessively time-consuming. The reason I wrote a scraper is so that I can parse out the relevant bits of the email and present it in a more efficient format (see https://staktrace.com/spout/entry.php?id=742 and https://github.com/staktrace/bugmash if you care more). I realize that the email format is not a stable API and changes are expected, but if you’re changing it anyway might I suggest making the format more friendly to automated parsing?

      • ah, thanks for the quick response.
        the changes to x-bugzilla-chaged-fields wasn’t expected, sorry about that. i’ve filed bug 785063 to address that.

  2. Since you’re changing the default for all users: how do I ensure that I continue to receive plain text bugmail?

  3. Is this limited in some way? I only see greyed out dropdown for “Preferred email format” which I can’t change at all.

  4. The option is disabled (greyed out). It is set at “Site default” and can’t be changed. What now?

Comments are closed.