Rockbox mail archiveSubject: Re: Release policy and coordination
Re: Release policy and coordination
From: Steve Bavin <pondlife_at_ntlworld.com>
Date: Wed, 31 May 2006 08:41:51 +0100
> I'd have to say that I'm loathe to come out of freeze until the core
> functionality is actually bug free. A lot of the difficulty with
> current Rockbox development is that while there are many people working
> on bells and whistles, not enough coders are working on making sure the
> darn thing actually plays music reliably. There has been some lovely
> work on plugins and the UI, but it's all a bit pointless if it doesn't
> work. 3.0 is more than a release. It's a stamp of approval and a mark
> of quality.
> Having said that, we can't stay in freeze forever, but if we don't have
> a release quality product, there's little point in coming out of freeze.
> The moment we come out of freeze, a whole slew of new features will go
> into the source, and a slew of new bugs with them. If the current code
> is flaky, how much more flaky will post 3.0 code be?
For whatever it's worth, this is my view too. Rockbox is software for
playing music, not Doom.
I own both an Archos Recorder V1 (10GB running a very stable post-2.5 daily
build) and an Iriver H340 (currently running a CVS build from 29th May). For
everyday use I'm sticking with the Archos as the Iriver stops voicing
regularly and much more importantly needs resetting pretty regularly too.
It's somewhat stessful if you get a hard crash, with backlight on and no
paperclip handy! ;-)
Unfortunately, I've not been able to find a reliably recipe to reproduce the
hard crash, but there's definitely something screwy going on. To be fair, I
do use a fair few features on the Iriver (voice, crossfade, resume) but
stability has to be the #1 aim. An unstable release is likely to be
counter-productive all round.
I've tried to debug, but whilst I can implement some "fixes", they're
probably just bodges that shouldn't be committed - mainly because the
documentation isn't there. I applaud Brandon's notes on the wiki - under
SoftwareCodecPlayback - but there really needs to be a bit more detail so
that us amateurs don't introduce more bugs than we fix. Notesnotes on which
source file is responsible for which functions would be a good start, along
with a diagram to show where crossfades/voice/different codecs/mixing etc.
are applied in the playback stream. (Yes - I know I should be working
through the code and working it all out for myself and documenting it for
others, but like everyone else, I don't have enough spare time at the
Sorry - didn't mean to rant!
Received on 2006-05-31