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