Mark Carter wrote:
> One of my fears about cinelerra is that there are a lot of git code
> branches out there, each doing its own thang, and I wonder how much good
> effort will ultimately be effectively wasted. Looking at
> http://www.pipapo.org/pipawiki/Cinelerra/GitBranches
> is enough to make most people's head swim at what's available. Look at
> one of the descriptions:
> "*ct* My branch/fork of cinelerra. Fixes, code cleanup and redesing
> *regardless of upstream mergability*.
The SVN was declared to be following HV and staying mergeable, hence I
started my 'ct' branch where developers can work without this brakeshoe.
When your ficl integration is finished I would be happily to merge it
there, if I don't have the time, just turn it, get my ct branch and
merge your work, publish it. Read on ...
> " My fear is that Cinelerra wont
> progress, but will just move around in circles, with users being left to
> decide which branch might best suit their needs.
Users should not come at the point where to have to decide, this is
where developers play with and finally agree about whats going into a
official distribution. Having developers work public is just more
transparent, note that many things in these git branches (ichthyos
bezier patches, pmdumuids widgetgrid, the bluedot theme fixes and many
more) predate the git repos. Just no one known/noticed that they where
hidden privately on some developers harddisks or forgotten as patches
once send to the ML. Having the code publically available with a
convinient tool is a big improvement.
>
> I almost feel there should be a committee of developers, perhaps like
> the PEP proposals of Python, or soemthing. Its purpose it to access one
> fact - the intergrability of any change. We basically want to know if
> any change will conflict with the change of anyone else, and work out
> ways of mitigating the problem.
I almost agree, using git gives us only the tool at hands to be able to
publish, distribute and merge code. There is still some need to make
decisions what goes into the distribution. I say this is a *big* problem
when working in a centralized way like with SVN, every commit has global
implications for anyone else so people better don't do decisions than
being blamed for breaking anyone elses expections. This might work in a
cooperate environment where is some big boss who decides whats to do and
what not. But in a community project where no one wants to take this
role this just does not work! People have to lobby their ideas endlessly
and still might be unheared, commiters which advance with new ideas get
blamed because the thing was not acknowledged, ...
For cin3 we now work in distributed way and everyone happily merges
everyone elses work, decisions are just done by the one which works one
some part and sometimes simply acknowledged on irc/via email. If cin3
gets some drive and more developers we might need some PEP process,
voting or some comittee. But so far it turned out that the current
friction-less approach works quite well. I would like to see such in
cinnelerra CV too but this would require some redefintion of the project
goals.
My ideal would be if free software could be done in a evolutionary
process, where good ideas are exchanged and reviewed between developers
and maybe seasoned/interested users (only a distributed revision control
system makes this possible). Good things will persist and be merged
while unimportant or bad things just get abadoned (but stay alive
somewhere in a public repo to be fixed or reconsidered anytime later).
Its true that distributed revision control encourages forking and
branching which leads to many many diverged copies. For a
closed/centralized project this is a horrific scenario. People need to
rethink this when they use distributed revision control, they have the
tool to merge such a diverged source back under their fingertips giving
them ultimate control of whats going into their branch.
That saied still means that git is just a tool to enable such a
workflow, for certain (many) things there is still need to communicate
and decide about a future project directions between the developers. imo
it becomes easier with git since it gives the right tool at hand to
branch, try and review ideas without global effect on other people and
without dazzeling with patches send per mail, but it is still only a
revision contol system not your boss or project manager which makes the
right decisions for you.
Christian
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
