From: David McIntyre <plughie_at_gmail.com>
Date: Mon, 6 Jun 2005 17:09:08 -0700

On 6/6/05, Linus Nielsen Feltzing <linus_at_haxx.se> wrote:
>
> 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.


Yes, but the code would still be present and operational unless it were
somehow deactivated.

> 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?


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
> 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.


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
> 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.


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
time).

> 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.


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. :)
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2005-06-07