In the last couple days, we’ve released versions 2.22.2, 2.20.4, and 2.23.4 of Bugzilla.
Version 2.22.2 is our current “stable” version. We’ve been intending to release this update to the 2.22 series for the last three months or so because it fixes compatibility issues with new versions of MySQL 5 and Template Toolkit 2.15. Those of us that deal with the actual mechanics of making a release happen (all on a volunteer basis) have had other things happening in real life keeping us from working on making it happen for the last few months. The issue got forced in the last couple weeks because of the discovery of a cross-site scripting vulnerability in the Atom feeds. Still, even with a fix for the security bug available the same day the bug was reported, it took us 12 days to release. This really isn’t fair to our users, and it certainly caused us enough strife with people who knew about it complaining about “when are we going to release?”
The process of getting a release pushed out the door (documented here) usually takes about 2 full days (with time off to sleep in the middle) for a single person to complete. It’s a lot of work. Max says he once managed to pull it off in 6 hours, but that’s probably an exception more than the rule. We all have “real jobs” other than working on Bugzilla, which makes even that a difficult chunk of time to be able to commit. We have found in the past that getting 2 or 3 people to work on it together (at the same time mind you, so they can coordinate), it can be pulled off in 3 to 5 hours. But we didn’t seem to find 2 or 3 people who could be in the same place at the same time to do it this time. This is all kind of a roundabout way of saying “we need help!” 🙂 If you look at the documentation link I provided above, the primary stuff we need help with is the pre-release section and the web site updates. Most of the stuff from there down on the list doesn’t take long, and can be done by the acting release manager in an hour or two.
Now that I have a working blog again, I’m going to make use of it and post here looking for volunteers the next time we’re ready to move on a release. 🙂 Our next release, barring any new security issues being discovered, will be a release candidate for version 3.0, but based on the remaining blockers in the buglist, it’s probably a month or two off yet.
Can’t more of the process be automated?
Gerv:
Some of it could be automated, but not the parts that take a long time. Those are mostly writing the security release, writing the news announcement, writing the release notes and getting them reviewed, etc.
I actually worked this time to make it easier to do the web page updates. Updating the Download page used to take a while, but now it should be trivial. Updating the changes page is a bit of a pain, and that *could* be more automated, but it’s tricky.
Updating the Release Info pages could probably also be automated, and so could tagging and building the tarballs and diffs. So we could cut a few hours off of the process, but the stuff that takes a long time would still take some time. Also, just having the free time to sit down and write release notes, even if they’re short, can be hard to come by.
-Max
Also, I’d have to have the time to write a release-automation script, which would take longer to write than doing an actual release. 🙂
-Max