Rockbox mail archiveSubject: Re: Bluechip forking
Re: Bluechip forking
From: sophana <jobarjo78_at_yahoo.fr>
Date: Tue, 08 Jun 2004 11:40:24 +0200
I know that maintaining a lot of build option in the same cvs branch is
hard to maintain (and validate)
But I think there is definitly something to do to implement lots of
things inside rockbox, while maintaining coherency.
A tool like subversion instead of cvs does help a LOT in managing branches.
I use it at work, and the branch management (and merging) is working great.
the linux kernel has TONs of options (with xconfig...)
rockbox has a (very small) configure script. It should exploited better,
don't you think?
I know that the most configurable, and the most complex it will be.
maybe each option maintainer will be responsible to maintain their
option up to date?
The number of waiting patches is clearly high...
> Unfortunately Rockbox as it stands cannot support the full complement
> of audio features available from the MAS chip.
> Since our recent chat about requirements for Rockbox to run Audio
> 3587, I also need:
> (access to mas read & write functions)
> a) access to the talk() functions - also not in the plugin interface
> b) access to lang.h (for the talk functions)
> Linus says this file will not be made available to the plugins (see
> irc log)
> Currently hard-coded into my plugin code - yeuch! :(
> c) Core changes to call my plugin when "sound settings" is called form
> the menu
> d) Core changes to call my plugin during startup for reg init
> (could be fixed with the "autoexec.bat" idea)
> e) Core changes to fade the volume when powering down
> I have submitted this change to sourceforge as I thought it was
> likely you might think it is cool and include it.
> f) Core changes so that the system understands a ".vol" (volume
> settings) file.
> g) Core changes so the volume display is shown using the new non-linear
> scaling algorithm.
> ...possibly other stuff I forgot right now.
> You can find a comprehensive list of all core changes I made by
> downloading this file:
> It it *NOT* my desire to fork, branch or maintain a seperate build of
> Rockbox. I would be over the moon if the required changes to the core
> code were implemented by Rockbox.
> I'm guessing, from much experience, it works this way: I release it;
> everybody loves it (and trust me, they will, this plugin opens new
> doors to quality sound); Then you guys want it built in; so it gets
> added and I am no longer required to maintain a seperate build.
> In the meantime I want to include a couple of other features which I
> personally feel are missing from rockbox such as filename sorting and
> volume triggered recording, so I thought it only polite to speak to
> the authors as their work is not technically GPL yet ...hence my posts
> to SourceForge.
> PLEASE realise that any talk of me "branching off" on a permanent or
> semi-permanent basis is conjecture, and wrong. It is NOT my intended
> outcome. My intended outcome is to impress you so much that you WANT
> to make the relevant changes to Rockbox so it can run natively :)
> Along with my contacting you directly on IRC, I hope you now
> understand my position accurately.
> P.S. "forked off" - LOL :)
>> > I would like to include this patch in the new Cyborg Systems branch of
>> > Rockbox with all the enhanced audio features.
>> Please don't use the Rockbox mailing list and the Rockbox trackers to
>> and work for your own project.
>> We use these services to work on Rockbox and you are now clearly off
>> on your
>> own project, forked off Rockbox.
>> I wish you success and happiness on this venture, please just keep that
>> separate from Rockbox as it clearly _is_ separate from Rockbox by
>> your choice.
>> -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
>> ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Received on 2004-06-08