For those of you who don't know what a postmortem is in this context, it's essentially a reflection of what happened in this release: what went right, what went wrong, and what we'll try to do next time.
Before I begin, a lot of the history is from memory, so the facts may not be 100% correct.
Back around July 2008 or so, we essentially had two branches: stable/bugfix-only (0.2.7) and trunk (0.3.1). A few developers wanted to release from the bugfix branch for the sake of the distributions, but since work was well on its way in trunk, there were not many volunteers to lead the effort. I volunteered to do so, and began merging bugfixes to the stable branch, with the goal of releasing by around the end of August.
Unfortunately, there were three big roadblocks in my way: the infamous make distcheck, Bug 194018 (an intermittent problem with launching launchers on docks not built with GNOME libraries, and Bug 194431, "the trash bug".
For developers, I would guess that one of the most annoying things about releases is the dreaded make distcheck command. This command makes sure that if you run make dist to generate a tarball, that it compiles correctly out-of-the-box. It took what felt like dozens of iterations to make sure that certain files were in the tarball, ready to be installed by the build system. But the most annoying part of the process was the part dealing with internationalization (i18n). I18n is handled by the intltool/gettext packages in Awn, and they expect files to be "just so", or else make distcheck fails with a semi-comprehensible error. With some help from Qball, I managed to more-or-less get the trees into a releasable state.
The desktop-agnostic launcher bug was a pain to debug, as all it did was spit out a cryptic error message to the console instead of launch the application, and this only occurred with some launchers (varying between machines). Fortunately, moonbeam managed to write a fix for it in early August.
The trash bug was more complex in its own way. In GNOME 2.22, GNOME switched virtual file system (VFS) libraries from GNOME VFS to the more desktop agnostic GIO (part of GLib). Part of this conversion was that the trash directory changed from $HOME/.Trash to the more complex Freedesktop.org standard of $XDG_DATA_HOME/Trash. In comparison to the old trash directory, which was just an intermediary directory prior to "permanent" deletion, the new standard added a trash metadata directory (e.g. for the "restore this file" feature). Now, the trash applet did not have a maintainer. As I understand it, Neil ported it from the GNOME applets package as one of the proof-of-concept Awn applets. By this time, Neil was (and still currently is) very busy with his awesome (but unrelated) work at Canonical. Thinking that this was a desktop-agnostic issue, I decided to take the bug. My first attempt, merging in the new trash implementation from GNOME applets, failed badly. My next move was to rewrite the entire thing in Vala. My reasons for doing this were twofold: I wanted to work on my skills in C#-like languages, and I wanted the applet to be a bit more readable/maintainable for the next person who would take up maintainership. Unfortunately, it took way to long to write (through no fault of Vala's). The main problem was that the algorithm to determine the number of files in the trash (an important part of the original applet) is ridiculously complex in non-GIO libraries. This is due to the fact that multiple volumes can have trash cans. By the time I figured out about half of it, it was the end of August. Given the number of people subscribed to the bug and commenting on it, plus the comments I saw on the forum, this was a showstopper bug. I couldn't very well release without it in there, so the deadline came and went, and there was no update to Awn in the fall Linux distribution release.
I should note that there will be a happy ending to this bug - last month, I managed to get trash support into libdesktop-agnostic, and as soon as I convert Awn to use libdesktop-agnostic, I will commit the Garbage applet.
Fast forward to last month (January). One of the core developers (mhr3) suggested that we do a snapshot release of trunk, since work on the rewrite was well underway. Somewhat surprising to me, more developers agreed to help with this release. This time, mhr3 was release manager (for obvious reasons). For the rest of the month and the first week of February, bugfixes were committed to the trunk branches of Awn and Awn Extras. There were also some features added (I admit that I added at least one of them), but the most notable one was the merging of the AWNLib 2.0 branch. I'll get back to that shortly. People were testing applets and noting their functionality on a wiki page, which helped with finding bugs.
By around February 6th, preparations were underway for the actual release. mhr3 and gilir were busy making sure that make distcheck worked for both Awn and Awn Extras, and I was working on the release notes. DBO, a developer for GNOME Do/Docky, suggested that we put some effort into doing a little marketing, like they did with their recent 0.8 release. So, I started a wiki page with a list of volunteers who would post to various news/forum websites.
The day of release was interesting. Throughout, various people (including myself) were in and out of the IRC channel doing stuff In Real Life. I managed to finish the release notes (and get screenshots) with the help of the folks in the channel, and gilir stayed up way past midnight local time to sign and upload both the source tarball and the PPA packages. As soon as mhr3 gave the go-ahead signal, the release announcements were sent to their respective news sites. I filed bugs in Gentoo for version bumps for both packages, to head off any overzealous Gentoo + Awn users. I also notified the Mandriva packager of the release, since I had his contact info handy. A few hours later, I remembered that I had an OSNews account (for commenting on some article which was probably tangentially related to Awn) and decided to submit an article. In the morning, I was informed via IRC (on a non-Awn channel, no less) of its publication, with a surprising addition: a mini-review by one of the site's editors, which was positive.
As of publication, my blog post announcing Awn/Awn Extras 0.3.2 has received almost 5,500 pageviews (see screenshot). To put numbers on the data points in the graph:
- Sunday: 312
- Monday: 2,783
- Tuesday: 953
- Wednesday: 1,008
- Thursday: 367
What Went Wrong
We should have reverted the AWNLib 2.0 branch merge. It caused more problems than it solved: it was inevitable that applets would break, and that at least one API change would be missed before release, especially given the amount of time between the merge and the release.
Coordinating the news/forum releases went OK, but we ended up having two Digg links, which probably spread out the total number of diggs, thereby lowering the chance that it would hit the Digg front page.
I was naïve enough to think that Debian/Ubuntu users wouldn't immediately file version bump bugs as some Gentoo users are prone to do. I was wrong.
Additionally, too many Ubuntu users did not read that we already provide binaries for Feisty through Jaunty (inclusive) - they seem to want to install from source, which we do not recommend (unless they plan on doing development).
What Went Right
The release coordination in the channel went fairly smoothly, especially given that we were all in different time zones.
Posting to OSNews was definitely a good thing. As you can see from the screenshot, it was the highest referrer to the post.
It was nice that someone not associated with the project posted to reddit - it was the second highest referrer. It was posted two days after the release, but beggars can't be choosers.
- First and foremost, prepare for a 0.3.2.1 release for Awn Extras.
- When we have a target date for 0.4.0, we should immediately branch, and said branch should only contain merges approved by the release manager.
- A 250-character summary of the new version (complete with reminders of what the packages are) should be written for news sites, in addition to the summary and the release notes.
- Make sure to highlight that Ubuntu users do not have to install from source.
- I need to get a Slashdot and a reddit account. I'm doing this under protest.
- We need to make sure that there's only one "official" Digg post.
- I should look into one of those omni-share-to-social-networks buttons, but only for the big announcements. Those "share" buttons make me feel a bit dirty.
- We need to get some contact information for at least the packagers for Fedora and OpenSUSE.
- If I remember and have time, I need to learn how to use the OpenSUSE Build Service.
- Explicitly mention in the release notes that there is no need to file version bump bugs in Debian/Ubuntu. Although, given past experience, I doubt that the people filing these bugs would read that. On the other hand, it's due diligence.