[chuck-users] Hello and the state of ChucK question

Harald Gutsche hg42 at gmx.net
Fri Apr 8 02:54:55 EDT 2011

> people can fork off from the main ChucK branch, tinker around, and if they do
> something cool, they can request that it be merged back in

Having a simple central repo, everyone can work on any number of local
forks of the project and work on them.
Especially with git or mercurial it is very easy to have several
branches around (in the same or in different working directories) and
push/pull/merge between them.

When something gets ready to be integrated in the main project, it can
be send as patch to one of the main developers.
This is where github (and now savannah?) adds a different workflow.
First, the main developers can integrate patches themself, without the
fork developer sending them.
So it can be used as pull model instead of push model.

But, on the other hand, as long as there is no request for
integration, the changes in the fork accumulate.
Integration of many changes at once can be very annoying, because
there will be many conflicts in the merge process.

If the fork developer tries to make a small patch for integration, he
will try to make this easy, because he wants to convince the main
The main developers have to do the integration work.

If the fork developer works on his own branch for a longer time, the
fork can easily drift away from the main branch.
But, if the fork developer regularly integrates changes from the main
branch, he does the main integration work.

One advantage of a system like github is the public fork repository.
The fork also gets a community process, so the code is reviewed and
tested and discussed by the community, before it makes it's way to the
main branch. Even the main developers can add tips and solutions to
the fork, also to make it better fitting to the main branch.

So, at the end, all depends on the way people work together. Each
model has it's advantages and disadvantages.
I think a github like system should especially be used, if the fork is
a bigger one, e.g. changing basic structures leading to changes in
many files of the project.

More information about the chuck-users mailing list