Max Kanat-Alexander

Hey folks! The Bugzilla Update has moved to its own blog:

http://bugzillaupdate.wordpress.com/

If you'd like to subscribe in your news reader, the feed is here:

http://bugzillaupdate.wordpress.com/feed/atom/

There's a new post today that has a LOT of news from the Bugzilla Project, over there. :-)

-Max

So, about a week ago I ordered an 80GB Intel X25-M G2 SSD, and as of a few days ago, it's running as my main system disk. It's a lot smaller than my old main disk (which was 320GB), but I just kept all my sound and pictures on the old main disk and moved the operating system over to the new disk, and that handled the size difference.

Now, having used it for a few days, I think that we are right at the beginning of the "SSD revolution"--that the curve where SSDs will start to replace hard drives for most common use is very close. Here's why:

• My SSD was 80GB and about $350 (and that's only because demand is so high that they increased the price from $270, right now). Although that's way more expensive than a hard drive of the same size, it's not unreasonably expensive, or beyond the purchasing power of a normal consumer.
• For normal dekstop use, the drive is about 5-10x faster than my old hard drive:
  • One part of the boot process on my machine that used to take 30 seconds now takes 5 seconds or less.
  • After I log in, it takes only about 2-3 seconds to present me with a fully-functional desktop with all startup programs running.
  • Most programs (including Thunderbird) start under 2 seconds.
  • Opening a new window or tab (including loading and fully rendering my iGoogle home page) in Firefox is instantaneous--under 1 second.
• The drive generates almost no heat--I've had it on for hours and it's cooler than my hand.
• The drive consumes almost no power compared to a hard drive.
• Physical dimensions don't matter--a solid state drive can be any physical size, and it's still the same speed (unlike hard drives, where small laptop drives are almost always slower than big desktop drives).
• Solid state drives produce no vibration and make no sound. For all intents and purposes (because I designed the rest of my machine to be very quiet) my machine is now totally silent during operation.
• The drive's physical orientation doesn't matter, and it can withstand being dropped or thrown around even when operating (obviously to a limited degree--if you hit it with a hammer, it will stop functioning). Because there are no moving parts, you can pick the drive up and turn it sideways, upside down, jiggle it--whatever--while it's running, and it will make no difference in performance or safety.
• All of the old problems that SSDs used to have (that they were slow, that they were unreasonably expensive, that they became slower over time, that they "stuttered" and locked up systems briefly) have now been resolved, and SSDs "just work".

Overall, it's the most significant performance upgrade I've ever made to a computer (other than giving enough RAM to a machine that was woefully low on RAM), and I'd strongly recommend it to anybody who can afford it, knows how to install it and copy over their OS, and who uses a computer regularly.

Now, if you're going to buy an SSD, it's important that you buy the right one, so read the latest AnandTech SSD Overview to understand how SSDs work and which ones are the best to buy.

A major security issue has been discovered in versions of Bugzilla back to 3.0. We will be releasing a version of Bugzilla which fixes the issue within 48 hours (possibly within 24 hours), and all administrators should be ready to perform the upgrade (which does not require any database changes) shortly after the new version is released.

If you do not wish to do a full upgrade, patches for just the security issue will be available. The patches are relatively small and do not modify very much of Bugzilla.

I have just posted the tarballs and done the website updates for Bugzilla 3.4! This means that we're out, released, ready to download, install, and go!

Bugzilla 3.4 is the best release of Bugzilla we've ever made. It has tons of great new features, the most exciting of which are listed in the release announcement, so I won't repeat them here. But you should go download it!

The Story of Bugzilla 3.4

As you look through the New Features list of Bugzilla 3.4, you may notice that it fixes tons of major issues that Bugzilla has had since its beginning. For example, we fixed the biggest performance problem in Bugzilla--sending emails when a bug is updated--and we finally hide email addresses from logged out users, to prevent spam. And that's just a tiny taste of what's new. Really, check out the New Features list to see everything.

But you may be asking yourself, why the sudden fixing of all these issues, and why didn't we do it before?

Well, that's an interesting story! From about 2003 to 2008, we spent nearly all of our time fixing up the code of Bugzilla. It needed a lot of refactoring, and we really did it--five years of it! We added new features at the same time as we refactored (remember, Bugzilla 3.0 had the largest number of major new features of any release we've ever done, and we were still refactoring), but the refactoring was our main focus. But finally, finally, with the release of Bugzilla 3.2, we fixed up one of the last major code issues in Bugzilla--we changed process_bug.cgi into a nice, simple series of steps that use Bug objects to do all their work.

After all this was done, we could finally take the time to look around and say, "What next?"

Well, what happened next was what led to such a great Bugzilla 3.4 release. First, I declared a new method of prioritizing work on the Bugzilla Project that put major issues of our current users as higher priority than adding new features for our prospective users. This led to us looking at the major survey items from our 2008 Bugzilla Survey and doing something about all the major requests that we could address immediately. Then we went through and looked at the bugs with the most votes on them, and did something about a lot of them.

And that, pretty simply, led to us addressing the things that people most wanted, and that we could actually prove that they wanted (because we had great survey feedback, or a lot of votes from individuals on our bugs).

Now that we've addressed so many of the individual things that users wanted, look to Bugzilla 3.6 and later for some big user interface and usability improvements--we have the results of extensive usability research that was done on Bugzilla, thanks to students from Carnegie-Mellon University, and we are already addressing the list of issues that that research generated.

Warning for WebService Clients: Changes Since Bugzilla 3.4rc1

Anybody who has been writing WebService clients against the 3.3.x or 3.4rc1 releases should know that we changed a few things in the API between 3.4rc1 and 3.4:

Bug.comments now takes an "ids" parameter instead of a "bug_ids" parameter (we just renamed the parameter to be consistent with out other WebService functions). Also, it will now throw an error if you try to add a private comment and you don't have the permissions to do so. (Previously it just added a public comment if you didn't have the permissions to make a private comment.)

Bug.history now returns its result in a completely different format, one which is more consistent with the format that Bug.comments and Bug.get use.

Progress on Bugzilla 3.6

Since our last Bugzilla Update just a few weeks ago, we've fixed several usability issues, sped up quicksearch, and added the ability to disable field values in global drop-down fields (without deleting the value).

Coming up soon, expect to see a lot of new WebService methods--there's been a lot of activity in adding WebService code, lately.

The End of Bugzilla 2.x

With this release, we EOL'ed Bugzilla 2.22, the last remaining supported 2.x release. That means that only 3.x releases are supported now. It's kind of wild to think that Bugzilla 2.x is "dead", after nearly ten years, and so much of my personal time spent on it. I started working on Bugzilla back in the 2.18 days, and I was pretty much the release manager for three major 2.x releases--2.18, 2.20, and 2.22. It's amazing to think that those releases were so long ago that now the very last one has reached the end of its support life. It's all Bugzilla 3.x (and hopefully 4.x soon) from here on out, my friends! :-)

Subscribe to the Bugzilla Update

There is an Atom feed that you can subscribe to and read in your RSS reader, for just the Bugzilla Update.

Today, as part of a larger project that I'm working on at Everything Solved, I published to CPAN a Perl module that I've been working on, called Parse::StackTrace. It parses the text representation of a stack trace from GDB (the GNU Debugger) or Python, and converts it into an object that will tell you all about that stack trace (or at least, as much as can be known from the text representation). This might be useful for anybody who receives text stack traces and wants to get information about them in some programmatic way.

-Max

Well, it's time for another Bugzilla update! And today I just did two releases, Bugzilla 3.4rc1 and Bugzilla 3.2.4.

Bugzilla 3.4rc1

Bugzilla 3.4rc1 is particularly exciting, because it's our first Release Candidate for 3.4. We did a really good job on this Release Candidate, I think--there's only one 3.4 blocker remaining (and it's only still there because we're waiting on an external party to do something). In other words, there are no known issues with the Release Candidate that are so bad that we couldn't just call it 3.4 next week if all goes well, and we've never actually been in that state for a Release Candidate, at least not as long as I've been around the Bugzilla Project.

One of the particularly exciting thing about a Release Candidate is that it has release notes! That means that all the new features are listed. There's a lot of really exciting stuff in 3.4, and you should take a look. There are some gems in the "Other Enhancements and Changes" section, too, so make sure you read that too. :-)

WebService Changes Since 3.3.4

Anybody who was writing WebService clients against 3.3.x development releases should know: we renamed the Bug.get_history method to Bug.history. You can still call it as Bug.get_history if you want, but that's undocumented and not recommended.

Also, we don't send <nil> for NULL items anymore--too many clients didn't support it. Now we just remove items from the returned result if they are undefined. (This is documented in the Bugzilla::WebService documentation.)

Progress Toward Bugzilla 3.6

There's been some activity on HEAD since our last update. We got a new WebService method to get attachment information, Bug.attachments. I've been working on making Quicksearch (the search box in the header and footer) even faster. Greg Hendricks (of Testopia fame) has been working on the ability for administrators to "disable" certain field values (so that they don't show up as options anymore, but remain set on existing bugs). And Bradley Baetz has been adding new hooks and working on improving performance in some important areas.

There's no ETA for Bugzilla 3.6, but if it works anything like how Bugzilla 3.4 works, we will have open development on it until two months after Bugzilla 3.4 is released, and then we will branch for 3.6 and the 3.6 branch will be "frozen" to only bug-fixes.

Bugzilla Meeting

We have a Bugzilla Meeting next week, on Tuesday, July 14. Just read the page if you want more information! Anybody is welcome to attend.

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, 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

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