David McIntyre wrote:
> It's like putting a stereo faceplate in a car on an assembly line and having
> the dealer tell the customer that the radio won't play because they haven't
> finished designing it yet. The code will run on an iRiver without playback
> right now.

Nobody mentioned iRiver. This release would be for the Archos users.

> You'd have to document that it won't work.

Of course.

> It's far better to release a build with all features intact and bug-free,

Get real. Have you ever seen a completely tested and bug-free program?

> If you really want to move forward on the release, I'd recommend branching
> the code by yanking the iRiver stuff and stabilizing the functional pieces.

Now that would be hazardous if anything. The Archos versions have been
functional all along, thanks to the daily builds. If we try now to
remove the iRiver stuff, we will certainly break the Archos code as
well. Then the 2.5 release will be more bug-ridden than the dailes
before it.

> We also have to ask ourselves if RLOD, recording fixes, and the database are
> worth the effort of freezing the code to iRiver development to get out an
> official release.

I agree about the freezing. A feature freeze would slow down the iRiver
development a lot.

> I'd recommend finishing iRiver and make a huge splash with
> the next release. It's a good milestone and should garner a lot more press.

Press? Who cares? I don't.

> In the future, if you have something like RLOD and recording fixes, these
> should be released as "dot-dot" builds instead of waiting a long time to get
> the fixes into the public eye.

Release early, release often. Amen. I don't see the point of having
extra "dotdot" builds instead of releasing a new, ordinary version every
now and then. That would only generate more work for us and more
confusion for the users.

Linus
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on Tue Jun 7 02:01:23 2005