Max Kanat-Alexander

Well, it's time for another Bugzilla update!

Bugzilla 3.4

In the Bugzilla 3.4 area, we just made some more changes to how the login form in the header and footer work. Now it's easy again for users to discover how to reset their password--when we moved the login forms into the header/footer, we at first didn't have any way for people to discover how to reset their password, but now there's a link and everything works really nicely. You can see how it all works on the Bugzilla 3.4 Test Installation.

We're getting somewhat closer to Bugzilla 3.4rc1. We found a few more blockers, so those have to be resolved, and there's also release notes that need to be written before we can have a Release Candidate.

One new feature of Bugzilla 3.4 that we haven't talked much about is the "See Also" field. This is a field where you can put a URL to a bug in another Bugzilla installation or to a Launchpad bug. The "See Also" feature isn't quite complete--in the future, we also want to make it update the other installation so that the other installation knows that you're referring to it. We also want to fix up the display, and get summary/status/resolution information on the remote bug, etc. But for now it does check that you've entered a valid bug URL, and at least you can somehow record that bugs in different Bugzilla installations are related to each other, and there's a WebService interface for updating the field.

For installations that don't need the "See Also" field, you can turn it off by disabling the "use_see_also" Parameter.

Bugzilla 3.6 (HEAD)

We're working on various interesting things for Bugzilla 3.6, though our focus recently has been on 3.4rc1, so there are a lot of patches awaiting review for HEAD that haven't had the time to be reviewed. People are working on the ability to disable field values and some cool WebService enhancements, but of course our main focus is fixing up the HCI issues that the Carnegie-Mellon research team discovered in their 2008 study.

-Max

I just created a Google Code page for the Supybot Bugzilla plugin (what bugbot is using to report changes):

http://code.google.com/p/supybot-bugzilla/

You can use that to get the code and to report issues about it.

I'd love to put the plugin's documentation on there, but the supybot-plugin-doc script throws a traceback when I try to generate documentation for the Bugzilla plugin, unfortunately.

There aren't currently any release tarballs on the page, but if anybody wants one, just ask me and I'll create one.

-Max

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 Bug.search 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.

-Max

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.

-Max

I switched to Thunderbird today and I am really loving it. So far, it's the best email client I've ever used. :-) It has so many nice things about it--but then again, if you're reading this, you probably already know that. :-)

-Max

I have proposed that Bugzilla have a new default status workflow. I wrote my reasoning in a message on the mozilla.dev.planning 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. :-)

-Max

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.

-Max

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. :-)

-Max

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. :-)

-Max

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. :-)

-Max

For those using bugzilla.mozilla.org, 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 bugzilla.mozilla.org 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.

-Max

So, fedorafaq.org 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 fedorafaq.org 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! :-)

-Max

Wow, so it's been a while, but I've just released VCI 0.5.1! This release focused on some pretty big performance improvements, and I also fixed some important bugs that were preventing the CVS and Subversion drivers from working in some environments.

If you're using VCI, I'd really like to know! I kind of live in a void, with it, because there's no way to get download stats from CPAN, and I only hear from people if they have a problem (and only then if they choose to email me!). So just let me know if you're using it, and if you like it, or if you think there's some improvements you'd like to see in it, or whatever! :-)

-Max

Let's talk about things that could be (or could have been) prevented if people cared more about the future than the present:

* Re-writing your software. It obviously should have just been well-architected the first time. (For anybody who's not paying attention, I have a whole website about this.)

* The destruction of New Orleans ("Oh, we'll never have a hurricane bigger than (blah).")

* The current financial crisis, and also the Great Depression. ("Oh, money can make money, that's a sound economic theory, let's all have our money make money!") (Note that I have never invested in the stock market and have always avoided loans when possible.)

And lots of other stuff. :-) Many people (the majority, apparently) love doing things that get them short-term gain for long-term loss, and that pretty simply seems to cause some large percentage of the misery in the world.

-Max

I don't know what's happened, but for some reason, but in just the last month or so, we've fixed almost every single long-term performance problem, security issue, and common support issue in Bugzilla. All of the sudden we've been really productive on attacking things that have been sitting around for just too long.

I suppose here's what happened:

1. We got out the Bugzilla 3.2 release, so we didn't have all our attention on that anymore.
2. Our architecture is finally at a point where it doesn't occupy all our attention just to maintain Bugzilla, and we're also not spending all our time fixing the architecture. So now we can actually focus on cleaning up all of this old "dirty laundry".
3. I finally started applying The Feature Acceptance Test to Bugzilla, which woke me up and suddenly made it really easy to prioritize things and realize what I need to focus on fixing. "Oh, what blocks Bugzilla from helping people fix bugs?", "Which of these features will most help people fix bugs?"--just asking these questions made it really easy for me to suddenly have a workable priority list.

Anyhow, whatever the reasons are, I'm really happy that we're doing it and I hope it keeps up! :-)

-Max

So, I recently posted a job on jobs.perl.org (which, by the way, I highly recommend if you're looking for Perl programmers) and a few other places. One of the things that the posting asks for is a code sample--one that they consider to be well-written. Reading these has been a very interesting experience, and I thought that perhaps some of you might find it enlightening (or amusing) to know what particular things will make me immediately discard somebody's application:

• If somebody doesn't submit a code sample at all, that's a very easy "no." If somebody can't follow a simple instruction like that (which is very clear in the job posting), then imagine trying to communicate client requirements to them!

  Some people have the problem that they always wrote proprietary code and they don't have the code available now to send. Okay, I understand that. But that also means that you've never written Perl for any personal project, and never contributed to any open-source project, neither of which are good indicators. (This is a good reason to work on open-source, by the way--it'll get you code samples that you can show prospective employers, later.)

• The very first thing I will notice in a piece of code is bad indentation or no indentation. If your code has no indentation or the indentation varies all over the place (or you mix spaces and tabs), I'll just toss it immediately. It could be the most amazing code in existence, but who cares? I have about two minutes to read your code, and if I can't read it easily, I just won't read it at all.
• Send me any code that doesn't "use strict", and it will go into the garbage. This is 2008. Perl 5 came out in 1995 people. Let's get with the picture, here. I don't care if somebody doesn't "use strict" in their little personal projects, but I ask people for a code sample that they consider well-written. If someone thinks that a lot of undeclared globals make for good code, then I don't really want them writing for my clients.
• If you name local variables things like $A and $B.... I don't think I have to explain this one. Reading the perlstyle manpage is not such a bad thing to do.
• If you write a few long comments without any punctuation, grammar, or complete sentences, then that's what I expect you're going to do when writing code for clients. I understand that some people don't speak English as their native language, but from what I've seen, the problem is more likely that the coder doesn't care or is a native speaker but doesn't have the requisite command of English to actually communicate sensibly.
• Don't print out a bunch of HTML in your Perl code, please. Just use templates. That's what they're there for. There's like, a zillion templating languages available for Perl, and it's really not that hard to use them. The Bugzilla Project put a lot of effort into moving to templates many years ago, because templates are a good idea.
• By and large, I'll discard anything that doesn't use at least some sort of object-oriented principles. There are ways to write good, structured code that aren't OO, but they're not that common, particularly in Perl.
• SQL that doesn't use placeholders makes me suspect that either you're not that familiar with DBI or you're traditionally a PHP coder. If you're at least inserting things with $dbh->quote, that's good, but given the number of applicants that I'm getting, it's not good enough.
• Even if your code is good, if you're re-inventing the wheel, that makes me suspect that you'll do the same when I give you work. I want my engineers to use the CPAN modules and great open-source software that already exists, not re-write their own webserver or something else like that.
• Using features correctly is good, mis-using them is bad. For example, I love to see POD in modules, but please use it standardly. There are ways to make lists of items (=over and =item)--if you want to make a list of items, that's what you should be using.

Also, some people are clearly spamming every job posting that they find--they have no cover letter to speak of, they don't respond to any of the specifics in the posting, and they attach no code sample. Maybe they think they're improving their chances by emailing everyone, but it's just spam--the chances are that it will be deleted without your resume being read, really.

Now, just to balance things out, there are a few things that I really like to see:

• Use Moose! This tells me that you're up on the latest developments in the Perl world, and that you probably have some good grasp of CPAN.
• Write POD for your modules. It's nice when people care enough about their code to document it properly.
• Correctly use CPAN modules, particularly modern ones.
• Use taint mode in your CGI scripts. Most people don't send me CGI scripts, but if you do, it's nice to see that you care about security. And Bugzilla uses taint mode, so it's cool to see that people can use it correctly.

Really, I want to see that people care about their code. This is professional development, not just local sysadmin Perl hacks. And anyhow, you're sending your code to me--and I put a lot of care into even my local sysadmin Perl hacks. Probably the hackiest thing I ever contributed to Bugzilla was recode.pl, and it's still better than most of the code that people send me.

-Max

So, Legend of the Seeker is on Hulu now, and I'm happy about that because I really liked the Sword of Truth series that they're based on.

I've seen several episodes now (I'd actually been watching them on TV a few weeks back before they were on Hulu), and I think that there is a definite problem with the series. Now, it's got incredible scenery, amazing sets, great costumes, and excellent lighting. The cinematography is a little weak at some points but by and large I don't notice it, which is a good sign. And it's a great story--that shows through even on TV. However, THE ACTING AND TIMING ARE ATROCIOUS. It's like the director was ASLEEP. The readings of lines that the actors choose...it's like they did everything on a first take, the actors didn't prepare, and the director had no vision whatsoever other than "Ooooh, pretty things!"

At first, I thought it was just the girl who plays Kahlan, who as far as I can see, couldn't act well enough to convince small children that she was even human. But after episode 5, I began to realize that most likely, it's the director, because everybody is bad. It's like a bad high school play, where the actors are still learning to memorize lines and can't spare any mental capacity for actually expressing anything with the words. I can see that the actors who play Richard and Zed are really trying, but it's like they're fishing in the dark.

Every line is flat. Every character--flat. You couldn't possibly find that many bad actors for a serious TV production. The director needs to be shot from guns and replaced with somebody who has some sense that no matter how much pretty scenery you throw in, it's the acting that's going to make or break the show.

-Max

So, I just released Bugzilla 3.2! That was pretty exciting. :-) It's been about a year and a half since 3.0, but there are actually a tremendous number of changes between 3.0 and 3.2--as many as there were between 2.22 and 3.0.

Some people might be wondering why this release isn't called 4.0, even though it's a major release. Well, that's all explained in the latest Status Update.

3.2 was the first release in a long time where we actually had some help from external companies, too. Xiaoou Wu of Oracle helped us with Oracle support, Red Hat contributed some work on the WebServices, and a few companies funded Everything Solved (my company) to write certain major new features, like the new types of custom fields in 3.2.

I also want to give huge thanks to Guy Pyrzak, the new UI Team Lead for the Bugzilla Project, who led our major redesign of the show_bug.cgi UI for 3.2. We have some other UI work coming up for you in future releases too!

Overall, I'm really happy with the direction that Bugzilla is going. Our architecture is getting better and better--I have actually enjoyed writing new features and customizations on the 3.2 codebase. It's that little "Wow, that was so elegant and simple to add that feature" feeling that's one of the great rewards of refactoring. (And boy have we been doing a LOT of that over the last several years!)

-Max

I just found out that January 31st, 2009 will be my grandparents' 60th wedding anniversary. Pretty wow.

-Max

Sometimes people wonder--how many Bugzilla installations are there? How many people are actually using Bugzilla?

This is hard to say. We tend to get around 100,000 downloads for each new version of Bugzilla, but we have no idea how many of those are complete downloads, how many of them result in working Bugzilla installations, etc.

However, Bugzilla has an auto-update feature which retrieves a file from one of our servers, approximately once a week, provided that a Bugzilla administrator has logged in that week. This was introduced in Bugzilla 3.0, but it wasn't working properly until 3.0.4.

In October 2008 we had 55,998 hits on the update file. Since Bugzilla installations check it roughly once per week, divide that number by 4 and it comes out to probably 14,000 Bugzilla installations that are using version 3.0.4 or higher (which is when this feature started to work).

I'd estimate the average number of users for a Bugzilla at around 200, with the major open-source installations having tens of thousands of users, and the smaller corporate installations having around 20-100. That gives us roughly 2,800,000 Bugzilla users around the planet, counting only Bugzilla installations that are version 3.0.4 and higher, have not disabled the update check, have an administrator who regularly logs in, and are not in an environment where they can't access the update file (which is actually fairly common in locked-down corporate environments).

-Max