On 6/6/05, Linus Nielsen Feltzing <email@example.com> wrote:
> David McIntyre wrote:
> > It's like putting a stereo faceplate in a car on an assembly line and
> > the dealer tell the customer that the radio won't play because they
> > finished designing it yet. The code will run on an iRiver without
> > right now.
> Nobody mentioned iRiver. This release would be for the Archos users.
Yes, but the code would still be present and operational unless it were
> 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
> Get real. Have you ever seen a completely tested and bug-free program?
I'm referring to documented bugs that have not been deferred.
> 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
> 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.
My argument was against releasing 2.5 at this stage in the development
process. Thanks for backing up my point. :)
> We also have to ask ourselves if RLOD, recording fixes, and the database
> > worth the effort of freezing the code to iRiver development to get out
> > 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? Who cares? I don't.
When you support iRiver, it's going to be press whether you like it or not.
A lot of people are buying them for podcast recording these days, and it's
the only currently-marketed device that can support Rockbox (or will in
> 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
> > 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.
Since a release build is now as trivial as pushing a button, it makes sense
to do releases with every major bit of functionality or serious bug fix.
Especially if you have other people doing the work. :)
Received on Tue Jun 7 02:09:46 2005