To The Side

Bugzilla Update: Wednesday, May 20, 2009

Hey hey. So, I was thinking that I'd do a regular (or semi-regular) post on the status of the Bugzilla Project, for anybody interested. This is the first one.

Bugzilla 3.4

We're getting pretty close to releasing Bugzilla 3.4rc1, now. There are only a few blockers left. Mostly they're just awaiting review. I'll also need some help with the release process for Bugzilla 3.4rc1, if anybody wants to help out.

The only significant changes since 3.3.4 will be a lot of bug fixes, a change to the WebServices API, and the ability to hide the "See Also" field. The bug fixes are pretty important, though, so if you're using 3.3.4 you definitely want to update to the most recent BUGZILLA-3_4-BRANCH code regularly or update to 3.4rc1 when it comes out.

There are a lot of significant changes in 3.4 compared to Bugzilla 3.2, though. Those will all be listed in the release notes for 3.4rc1. The difference between 3.2 and 3.4 is not as great as the difference between 3.0 and 3.2 though. We're working on having smaller releases more often (starting with 3.4), and it seems to be working pretty well so far.

HEAD (Bugzilla 3.6)

On trunk (which will be Bugzilla 3.6), we've done a fair bit. There's a JSON-RPC interface, support for suexec environments in checksetup, and a lot of HCI improvements. We've decided that for Bugzilla 3.6, our focus isn't going to be adding major new features, but fixing up the features we already have. I wrote a message to the Bugzilla Developers List about it, a week ago or so, and I got a lot of positive responses (mostly on IRC or by private email). If you're interested in helping out, feel free to check out the list of bugs we'd like to fix for Bugzilla 3.6.

To The Side

Fixing HCI Bugs in Bugzilla

Guy Pyrzak led a bunch of Carnegie-Mellon students in conducting some HCI research on Bugzilla, and they came up with extensive and detailed results.

I have been working on filing bugs in response to their results. I haven't finished filing all the bugs yet, but if you want to follow along with the issues as they are filed and fixed, you can watch the tracking bug I filed to keep track of all the usability issues discovered during the research. Some of them are minor issues that now already have patches awaiting review. Some of them are larger issues that will require work over time to fix. But I am committed to seeing them all fixed as we move forward.

We've fixed Bugzilla's backend pretty well, now. It's time to focus some on the front end.

Anybody who wants to help, please do. Any of the bugs that block the tracking bug and are assigned to "Nobody", you are welcome to take and work on yourself.

To The Side

New Default Bugzilla Workflow?

I have proposed that Bugzilla have a new default status workflow. I wrote my reasoning in a message on the newsgroup, originally as an argument for a workflow that Mozilla should move to, but I think that it covers the basic bug-fixing process sufficiently well as to apply to all organizations, and thus should be the default.

I'd welcome constructive feedback, even just statements of agreement. Note that I said "constructive" feedback, not insults or rudeness, which I will most likely just ignore. :-)

  • Current Music
    Death Cab for Cutie - Talking Bird (Demo)
  • Tags
To The Side

When does form autocomplete happen?

Today for fixing a bug in Bugzilla I needed an event to fire only after the browser had automatically autocompleted the login form (what Firefox, Chrome, and Safari do when you have saved exactly one set of login credentials for a site). Most people would think that window.onload would work, and it does, in one browser--Chrome. Other people might try to use YUI's onDOMReady event, which fires when all the content is available in the DOM. That works in exactly one engine--Gecko.

The problem is that autocomplete happens at different times in different browsers, and you can't even rely on knowing what engine the browser is using--in WebKit-based browsers, it happens at different times depending on what browser is being used. Here's when autocomplete happens in different browsers:

  • Gecko: Before onDOMReady, but after window.onload (so use onDOMReady).
  • Chrome: After onDOMReady, but before window.onload (so use window.onload).
  • Safari: After both onDOMReady and window.onload (so do a 200 millisecond window.setTimeout on window.onload).
  • Opera: Never autocompletes forms without user interaction.
  • IE: Never autocompletes forms without user interaction.

So the only reliable solution is to fallback to the Safari solution, which is to do something 200 milliseconds after window.onload. I tried 100ms, and I was getting into race conditions where sometimes my event would fire before autocomplete, sometimes it would fire after. I upped it to 200ms as a safe amount.

This is a little annoying if you want something to happen instantly after the form is autocompleted, so what I actually did for Bugzilla was I fired the event after onDOMReady for Gecko, and used the Safari solution for all other browsers.

Anyhow, it would be nice if this was all standardized some day.


To The Side

Fushigi Yugi

So, I just finished watching Fushigi Yugi. It's definitely an older anime, with a more traditional style--almost a more serious and delicately-crafted Dragonball Z with more of an appeal for girls (but still basically an action show despite all the emotional content). I thought the show did best when it was focusing on action, and whenever it started to get weepy I'd kind of roll my eyes and wait for that part to pass. :-) And it's not that I'm opposed to emotion in shows--on the contrary, how else I could I have loved Honey and Clover so much? No, the weepy bits of Fushigi Yugi were just not that great. :-)

Overall I'd give it like a 5.5 out of 10. Almost everybody has seen it, I think, so I think in a way that makes it worth watching just so you can bond over it with other people. And it's not bad. I thought the ending was pretty decent, and the beginning was pretty strong. It got a little dull about 3/4 of the way through, but picked up pretty well in the last 1/8th or so.

One great thing about the series is that you get like 6 to 8 episodes per disc! They didn't fill the discs up with silly extra features or anything, they just put more actual episodes on them, which is soooo much better than the discs for any other series I've watched. I mean, I think I've even heard of series where they only put 1 or 2 episodes per disc...Fushigi Yugi is positive proof that nobody actually needs to do that.

Still, even with all those episodes per disc, there were something like 8 discs. It's definitely not a short series! It didn't feel all that long, though, somehow. Perhaps it's that since there were so many episodes per disc, I would watch a lot of episodes at once! So it didn't take all that many sessions of watching to finish it. :-)

Anyhow, glad to have seen it, but really glad to be going on to something else now--maybe even some normal movies or TV series for a little while, taking a little break from anime. Well, except for the Azumanga Daoih that justdave lent me--I do want to watch that! :-) So I guess it won't be a total break. :-)

To The Side

The iPhone SDK

So, if Apple was wondering about me, and perhaps picking the petals off flowers going "He loves me, he loves me not," I think this time we ended up on "he loves me not."

The iPhone SDK only works on Mac OS X.

I do not own a Mac. In fact, I'm pretty sure I don't own any machine on which OS X will run.

The explanation for this is, "It's all built around XCode and Objective C which don't work on other platforms."

Let's back up.

Why isn't XCode based on Eclipse? Then it would run on every platform.

Objective C works on Linux. Linux is an OS that developers use. Wouldn't it be nice to have an SDK that developers could use?

If the simulator only ran on a Mac, well okay, that wouldn't make sense since Macs are now Intel machines, but maybe there's some graphics interfaces that don't exist on other platforms. Fine.

But can't I at least get the ability to develop an iPhone app using the platform of my choice, instead of being ASSIMILATED INTO THE BORG COLLECTIVE just to write a program?

I expect to get approximately 1 billion comments now, since I'm complaining about something. It seems that happens whenever I complain about something. :-) Ah well. :-)

To The Side

Bugzilla 3.2.1, etc.

So, today we released Bugzilla 3.2.1, which fixes the longest-standing security bugs in Bugzilla, in addition to a few other security issues. These long-standing security issues were actually public for many years, but it required a lot of re-architecture of Bugzilla before we could fix them.

We also released 3.3.2, which has a lot of cool new features, not the least of which is hiding email addresses from logged-out users.

And we put out Bugzilla 3.0.6 and Bugzilla 2.22.7 as security fixes for people still using those older branches.

Anyhow, you can read the news announcement for more details, and the Security Advisory if you want to read up on the security issues that were fixed.

It feels really great to have these releases out. Although I haven't ever heard of a successful exploit of these security issues, they've been around for so long that it was naggingly worrying to have them there, and it's a huge relief to have them fixed and see the fixes released!

Anyhow, here's a bit of news about Bugzilla trunk, which will be Bugzilla 3.4:

- Our current estimated release date is sometime in May, but that's a very rough estimate.

- We're now in a soft freeze (since Jan 29), which means that enhancements that had patches before Jan 29 can still go in, but any enhancements that didn't have patches at that time can't go in. This allows existing patches some time to pass review and to clean up any feature work that wasn't quite done before the freeze.

- There are a few nice enhancements that should still be coming, including a simplified bug entry page.

- If there are any other long-term major problems that you see in Bugzilla that we haven't fixed in 3.4, please let me know. Point me at a bug, or anything you want. And I don't mean minor things, like the positioning of a button or some text on a page, but big things like how emails used to be displayed to logged-out users. :-)

  • Current Music
    Eagles - Center of the Universe
  • Tags
To The Side

The Dusk skin and

For those using, I wanted to let you know that when we upgraded to 3.2, you got access to a new Bugzilla skin called "Dusk." Though I've been attempting to convince the admins of the site to switch over to usnig Dusk by default, it hasn't happened (yet?). So, I wanted to let you know that you can change Bugzilla's skin to Dusk yourself, using the General Preferences page.

Dusk is much nicer than the Classic skin, in my opinion, and I think Bugzilla actually becomes more usable with it. If you want to see what it looks like before you switch over to it, you can either use the "View > Page Style" menu in Firefox, or you can look at our test installation, which defaults to Dusk.

To The Side

New Design For

So, has had the same site design for many years. It was okay, but I thought it'd be nice to have a newer, even cleaner design (the top of the page became particularly cluttered with the old design). Also, I had this realization about visual design (this will probably be the subject of a separate blog) and I wanted to try applying my new theory. I figured would be a good place to test it out. :-)

Anyhow, before this, I probably never, ever made a website that "looks nice." But I think that thanks to my realizations about visual design, the new design came out pretty well! :-)

  • Current Music
    Bob Culbertson - Toccata and Fugue in Dm
  • Tags