If you'd like to subscribe in your news reader, the feed is here:
There's a new post today that has a LOT of news from the Bugzilla Project, over there. :-)
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.
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.
So anyhow, if you're interested, you can read my favorite blogs that I've written, and comment on them too, if you want. I'll always respond to nice comments, even if they're on very old blogs. :-)
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.
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.
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.
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.
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.