Well... first a correction. We have 3 'versions' of Rockbox (see FAQ #64)
'Release': fixed feature set.
'Daily-builds': all cvs commits from the previous day
'Bleeding-edge': all cvs commits upto to the last 20 mins.

Now.. what I would suggest, is if you want to host a seperate branch you
are more then welcome to. However, you will have your work cut out for
you.

Which 'version' do you use?

Which patches do you apply?

Are you going to keep the patches up to date as the original developer
updates them?

The patches you apply may be buggy due to the choice you made regarding
version. Namely a bug caused by something that was fixed in daily/bleeding
edge builds.

Just because you include a patch, does not mean it will be included in the
main tree. Users need to be aware of this.

How will you account for patches that conflict?

You see where I'm going with this? I'm not nay saying it. The idea has
merit. I just think the 'name' of the branch is the least of your
concerns.

/Adi

On Wed, 5 Feb 2003, Fred wrote:

>I see little gain in having tree official branches
> There is a reason we choose to merge certain patches at certain points in
time.

The "unstable" would only be a testing release, which would allow users to
send feedback and say what they'd want to be changed, how the software
works, if it's mature enough to be integrated to the main RockBox source. I
love to live on the edge, and I'm sure I'm not alone. The average RockBox
user may not be able to patch and compile the source, or even doesn't have
time to do so, but this "new" build may require a specific name, as it'll be
the third available one.
I can understand you want more explicit names (the Debian names were just an
exemple ...) but I think it should be time to name the releases and give the
code evolution a structure.

> Why not be less cute and more explicit? Call them stable, testing and
unstable.
Stable for the official releases, Cvs for the direct-from-CVS compiled
sources and Patch for the unstable patched ones, would you agree with this ?

Making the patches available through the Patch build doesn't mean you have
to integrate it one day or another to the main source : it should be a
showroom, a feature-testing and a bug-tracking solution. The users should
say if they want the patch to be integrated to the source, what needs to be
changed until that, and what they're thinking of the rockbox' latest
patches. This would be quite usefull I think ... if you don't agree with me
you just have to say it, doesn't matter if my release should be public or
not, it's a private release at first intention :-D