Waiting for Rockbox 3.0

Frequent LWN readers will be well aware that your editor has had some real fun playing with Rockbox, a set of GPL-licensed firmware for digital music players. So the Rockbox 3.0 release, originally scheduled for March 15, is of more than passing interest. This release will offer a number of new features:

• The addition of the iRiver H1xx and H3xx players as fully-supported targets. Rockbox works on a number of other players as well (notably iPods and the iAudio X5), but those platforms are not quite ready for a stable release yet.

• Several new games, including Jewels, Brickmania, Chessbox, Bubbles, and others. Players with suitable displays can even run Doom.

• Support for Unicode and translations to 28 languages.

• New codecs, including WAV playback on Archos models and AIFF.

• The Tag Cache music database, allowing the user to browse through the collection based on several attributes.

• A built-in five-band parametric equalizer.

• High-quality, lossless recording on platforms which support it.

There are, of course, many other improvements to the code which help to make it more robust and maintainable, but which tend not to show up on feature lists. Your editor has been running the occasional daily build with good results. This looks to be a release which exposes Rockbox to a wider user base and, in general, draws more attention to the project.

Only one problem remains: it doesn't all work yet. There are a number of codec issues, such as confusion when the user skips around too much. A number of trouble reports with the H1xx models have been posted. Battery life on the H3xx is still far less than with the iRiver firmware. In general, the list of open bugs is on the long side for a project on the verge of a stable release.

The Rockbox developers thus find themselves in a place familiar to many projects: trying to decide when to make a major release. Putting out a buggy system would not endear Rockbox to many of its users, and could set the project back severely. Meanwhile, however, the ongoing feature freeze has brought development to a stop and is creating a fair amount of patch pressure. The developers would very much like to get this release out of the way and move on to working on the new, fun stuff.

Getting releases out is one of the biggest challenges faced by many free software projects. There is a natural tension between the creation of truly stable releases and going on to develop the Next Cool Thing. A number of techniques have evolved as a way of resolving this conflict:

• Strict time-based releases, as characterized by projects like GNOME or OpenBSD. Some projects would appear to employ a low-stratum network time protocol server to time their releases to the millisecond. This approach solves the "when do we release?" question, but it will not be suitable for all projects. It would appear to work best when the project is made up of many independent components, any of which can be dropped (or kept at an older version) if they are not ready at release time.

  Interestingly, the Linux kernel has moved slowly toward this mode over time with its 6-8 week process.

• The "when it's ready" approach. Waiting until no (known) critical-level bugs remain can lead to stable releases, but on an indeterminate schedule. Debian's stable releases highlight both aspects of this approach. The older (2.4 and prior) kernel model also worked this way.

• Separate stable and development branches. In theory, this approach allows development to go forward without disturbing the branch intended for the stable release. The pre-2.6 kernel sort of used this approach, except that the development branch was not created until a number of stable releases and updates had gone out. The Mozilla Foundation has used an approach like this as well. The problems here include a certain tendency for developers to go play in the unstable branch and not work on fixing bugs and difficulties in propagating important fixes between the two branches.

The Rockbox developers do not appear to welcome the idea of creating a separate development branch. So some sort of compromise between a timely release and a bug-free release will have to be found. There is some sentiment for putting out 3.0 on Monday the 22nd, with known bugs if need be. The worst of those bugs might subsequently be fixed in an update release shortly thereafter. So, while Rockbox 3.0 will doubtless make many users entirely happy, it may well be a true "dot-zero" release for others.

---

to post comments

>>>---Joke--->

      Head