dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Bluechip forking - "There is no Fork" [BlueChip 2004]

Re: Bluechip forking - "There is no Fork" [BlueChip 2004]

From: BlueChip <>
Date: Tue, 08 Jun 2004 13:37:26 +0100

Am I in the Matrix?

Just felt the subject line should be corrected :)

An IRC chat has been held (and logged) where all issues which stopped the
enhanced audio features from working with rockbox as it stands (bar one
minor one) have been added to the "todo" list and so it is just a matter of
time before Rockbox gains this new strength :)

The unresolved issue is using Audio_3587 as a COMPLETE replacement for the
current system (by an on/off menu option if necessary) but that will happen
once people post about how much they like it.

Of course, if a load of people post that it is a downgrade, then I will try
to come up with something even more wonderful.

You are the people who get to decide whether this advanced audio plugin
should be supported by Rockbox natively.


>>>the linux kernel has TONs of options (with xconfig...)
>>>rockbox has a (very small) configure script. It should exploited better,
>>>don't you think?
>>More options means more builds, and more combinations in which to hunt bugs.
>>And the fact is that most people (I'd guess >95%) don't know how to
>>compile their own build, and so for the vast majority this work would be
>I totally agree that options brings complexity. But it brings features also!
>I don't think the option management would be wasted. It allows your mod to
>evolve with rockbox.
>making a web interface script for configuring and compiling rockbox from
>cvs would be great.
>there is actualy some code for maintaining all the archos hardware
>versions. This same code could serve the additional optionnal rockbox
>features? a specific make target would try to do a compile-regression test
>with all option space.
>maybe the firmware-linkable plugin feature would allow people to compile
>their mod everytime with rockbox, but the user would choose dynamically
>the features he wants by loading or not the plugin...
>At work, we made a modified version of gmake and a set of rules which does
>handle that kind of problems. Too bad it is not released.
>All the great features contributed by lot of people make rockbox a great
>piece of code.
>The more feature there are the greater rockbox will be. (in my opinion)
>>>The number of waiting patches is clearly high...
>>Yes, but that is not helped much by making branches in the version
>>control system. A branch is no different than a patch.

Received on 2004-06-08

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy