The Agony of Release

In the Rockbox project we haven’t had an official release in several years. We have >400K lines of code, some 60 committers. Some 300 patch contributors. At least 10,000 users, but probably up to 10-20 times that number.

We produce binary downloads after every single commit. We provide daily builds with a 30 day backlog. We provide a UI-based installer that can install the latest package for you.

So, we have a fair setup that provides releases in a fine way to everone interested. What we don’t have is a stable offer. Nobody can get a recent “stable” release (with a set of known bugs) or similar. We only have this endless series of “beta”-releases. We don’t have any particular push for doing a “real” release and among the developers there aren’t that many who think making releases is any fun, so we’re not really striving towards that.

The last time we tried to put together a release (to be called “3.0”) we decided to have a feature freeze period in which we’d only commit bug fixes and not do any new features. This lead to that most people simply stopped committing and developed their new stuff on the side, waiting for the freeze to go over. Only a few people did any actual bugfixing while we had some pretty serious flaws still in the code, so even with extended freezes we just couldn’t get the bug count down to a satisfiable level… we ended up just dumping the idea of a release 3.0 at that time, and it left some scars in the community that has so far prevented us from returning to this topic.


This said, today we’re more than 18 months further down the road, Rockbox runs on many more platforms, lots of code has changed and been improved since the previous 3.0 effort. Maybe it is time to once again make a release-attempt?

I think there are a few preconditions we need for this to succeed, including:

  • We need a single release manager person who single-handedly can decide when the release is finished. This person would also have the final say on the outstanding-issues list etc. We can’t manage to get consensus among this large amount of people for this black-and-white style of questions.
  • We need to accept that fact that some bugs just have to be in the release and we can live with them – after all most of these sorts of bugs have been with us for a very long time already and all of us have managed to live and use Rockbox fine for years in spite of their presence.
  • We need to accept and realize that most of “us” – the devs, the closest team of followers, will not use the release anyway as the day after the release we will provide a new set of spanking fresh binaries to download and use… We don’t do the release for us. We do the release to the huge audience out there who look for “stable” and “known to work” stuff.
  • Less people need to worry and have strong opinions about exactly what goes into the release or not. If we just get one release out, there will follow more further on that will get the stuff that is left out in this!

I am officially not volunteering to be a release manager! 😉

Sansa View Info

So we know a bit more about the Sansa View’s internals now!Sansa View

It is based on a PP-derivate, possibly called PP61x0 something.

It has a “disk” (NAND flash) layout quite similar to the Sansa E200 in that it has a “hidden” second partition in which the bootloader, firmware image and more are stored – in just about the same format as the Sansa E200 has its images. See my separate Sansa View page for more details.

And announced on CES going on right now, and also now mentioned on their official site, it is also available in a 32GB version.