I'm afraid that despite offering to shepherd this release through, I
haven't been able to follow through on that for the usual reason (poor
health). My regrets that that's left a void, but it's been unavoidable
Daniel Stenberg wrote:
> A) drop H300 from the release and ship Rockbox 3.0 for Archos and
> iriver H100
> on friday.
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
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?
One of the really strong features of the Rockbox 2.x series has been
that it's been stable for a long long time. Releasing 3.0 as a step
back in stability would be a big disappointment.
Having said that, I'm really not sure how to fix the issue of the fact
that there's not enough knowledgeable people working on the code. I'm
as guilty of this as the next coder - I'm the first to admit that the
playback engine is voodoo to me - but I can't see myself having the time
to devote to understanding it properly in the near term.
The bottom line: if we want to release Rockbox, we need more coders
willing and able to get to grips with both the firmware layer and the
Received on Wed May 31 01:11:08 2006