Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Could you explain this more? svn allows branching, so why not just create as many development branches as required and work there? I do not know git, so could you please explain what git has over svn? (Not intended as an attack). On 16/08/07, Christian Thaeter [EMAIL PROTECTED] wrote: ... 2) Stop using SVN Even if commit access is generously handled to people who ask, it's still a big blocker as I explained earlier. As long we have only one linear history everything has global impact and there is no easy way to add new features without running in troubles. There is no easy way that small groups of people try and review new features, no easy way to get good but intrusive new ideas back into CV. -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Martin Ellison wrote: Could you explain this more? svn allows branching, so why not just create as many development branches as required and work there? I do not know git, so could you please explain what git has over svn? (Not intended as an attack). I am out of office today. In short: SVN allows branching but does not support (enough) merging and has many many more problems. Best let linus explain: http://uk.youtube.com/watch?v=4XpnKHJAok8 Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On Thu, 2007-08-16 at 16:37 +0800, Martin Ellison wrote: Could you explain this more? svn allows branching, so why not just create as many development branches as required and work there? I do not know git, so could you please explain what git has over svn? (Not intended as an attack). SVN is centralised, git is decentralised. Git is reputably easier to merge. It also has scalability advantages, esp. wrt branching. In git, there is no authority. If I want to add a cool feature, I fork a repository, and add a feature. My repo then becomes one among any number of forks of the project. It is successful for Linus on his kernel development, but I think in Cinelerra it has lead to a bit of a mish-mash - surprising since the Linux kernel is undoubtedly a 2,3,4 or even 5 orders of magnitude more complex than Cinelerra. I think the problem is that git is good at creating forks, but merging is a social issue. So I might create a cool feature, but there's no guarantee that it will make it upstream. What Linus does is have a core of developers who he trusts, and he willingly accepts patches from his core team. He probably doesn't even look at what anyone else does. Now, those core developers probably work in key separate areas, meaning clashes are kept to a minimum. The core team, in turn, have their trusted sources - and in this way, the whole thing builds like a pyramid with Linus at the apex, Lord of all he surveys. Now, I could go and take a copy of the Linux kernel, and immediately produce a fork, declaring my branch to be superior. But that's a really bad idea. It's a bad idea because no-one is interested in my fork. What I probably should do if I want to submit a patch is branch something that is interested in the kind of patch that I want to contribute, and whose branch is eventually propagated upstream. And I think this is the main problem we're seeing in Cinelerra: lots of branches, but no upstream merging. So we're seeing lots of people making useful contributions. but that the code is just whithering on the vine. And I strongly suspect that as time goes on, the patches will become unmergable. Probably git is much better at svn when it comes to merging; but like svn, it isn't able to magically resolve code conflicts. I think what I'm saying is that git is merely a tool, it doesn't solve the social and organisational issues. That's for humans to sort out. At the moment, what I see, as I understand it, is: * Cinelerra-HV, which is Heroine's version * Cinelerra-CV, which is basically HV plus or minus a few patches, * ct, which is happy to part from both, attempting to bring architectural improvements and some bug fixes * cinelerra 3, which is basically a Cinelerra redesign * a number of other players (including my branch), which attempt to do various things in various combinations Git makes it easy to create forks. But forking is a serious business, and shouldn't be undertaken lightly. I think interested parties really need to discuss this issue. And perhaps we should be asking the question should we even really have a Cinelerra-CV version? Another key question might be: who produces the most code: HV, or CV? If HV is chugging along at a steady pace, rarely accepting patches, whilst CV is mired in difficulties, then one might form the conclusions that it's better just to use HVs code, and forget about CV, or maybe just use it for occasional minor bug fixes. OTOH, if the opinion is that HV is sluggish, buggy, and the CV version would be more dynamic, then we should probably conclude that we should form a proper fork, probably using git, and let HV play catch-up with us. It all depends what you think. ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On 2007-08-16 00:49, Christian Thaeter wrote: Kevin Brosius wrote: On 2007-08-15 17:36, Christian Thaeter wrote: ... I think you won't get much feedback from the older core developers since these goals are so large and you haven't tackled a smaller piece of Cin first. I have done little work in my branches but get demotivated by this 'bottomless pit' discovery and that there is no much perspective to get new things merged into the SVN trunk because it breaks the current concept. I think thats exactly what many other potential contributors see. There are patches and contributions rotting somewhere. Well, this 'patches rotting somewhere' is an argument without evidence that you seem to keep making. You understand that we've had a standing policy that patches get added to the bug tracker for best tracking, or sent to the mailing list if you can't be bothered to add them to the bug tracker? They don't 'get lost' either place. A search will turn them up easily (which is one of the reasons I personally like these methods.) Maybe these patches you mention are rotting in git somewhere? ;) The more places people are told they can submit things, the more confusing it is. I only know of one or two Cin people that might go look at the git repo for patches, so if they don't get mentioned on the mail list or bugzilla, then they are going to rot there just as easily. And while mob is a cute idea, you'd better tag things with email addresses or some other contact information. If we can't come back and ask questions, verify platforms, or test cases, I'd question the value of any anonymous contribution. That just leaves you with a much larger pile of average quality code that you can't get further info on. Do you have any experience over 6 months on a large software project to have an idea of what it takes to get a usable product out? -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On 16/08/07, Herman Robak [EMAIL PROTECTED] wrote: ... Adam would not be able to fix this in a reasonable timeframe, even if he was given an exhaustive TODO list. Neither will we, unless a lot of the underlying code is redone to support all the stuff that an NLE and compositor of the future should support. It has to be maintainable, extensible and reasonably layered. It needs to be elegant and beautiful, too, or too few coders will be attracted to it. Doesa anyone know Adam's views on the questions that we have been discussing recently? -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV Currently CVs goal is repackaging the HV version and fixing bugs. But a real community version should acknowledge progress and new features which are contributed by the community. 2) Stop using SVN Even if commit access is generously handled to people who ask, it's still a big blocker as I explained earlier. As long we have only one linear history everything has global impact and there is no easy way to add new features without running in troubles. There is no easy way that small groups of people try and review new features, no easy way to get good but intrusive new ideas back into CV. 3) Make releases Cinelerra CV has only this SVN there is no release schedule and no defined point when the source is called to be stable (well we can't define in a lack of testsuite and presense of many bugs anyways). This yields the result that anyone (including distributors and packagers) build on some (maybe recent?) svn revision. There are packages from many different versions out there which makes it not really easy to track reported bugs down. Users have doubts which is the best version for them already just because this linear revision history without release statements, which is imo more worse than a magnitude of git branches with defined releases (and maybe bugfix revisions on them) 4) Make tracking HV less important We want some branch which tracks heroines versions and refactors it into smaller commits as we are doing now, but this should be considered as tool and foundation of any work which is done on our releases. This means the CV version should be maintained in another branch and new features should be added on our development (or release) branches. Finally we may provide a backporting branch where imminent bugfixes are prepared to be mergeable with the hv-tracking version. So this becomes a way how we can contribute back to HV which is currently not a easy case. Maybe Adam once speaks about what he wants, so far he complained that the community didn't provide much useable feedback .. and admitably he was right, takeing HV less important will actually allow us to do more work and thus may provide more benefits for HV getting some contributions feed back. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Christian Thaeter writes: This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV [ ... ] 2) Stop using SVN [ ... ] 3) Make releases [ ... ] 4) Make tracking HV less important Hear hear. I've been reading this thread and this is precisely what I would have liked to have said, but I'm not a developer so it's not my place to say. But even to an outsider, it seems that both communication and code exchange with HV is much, much too infrequent, and that this is holding things back. Btw. regarding the debate about the graphical interface and the style of icons, I'd suggest people take a look at the Jokosher project. Jokosher is an recording studio / nonlinear editor for audio, and it has very much focused on usability from the start. Imagine a first-time user trying to use something like Jokosher on one hand and something like Cinelerra on the other. I _like_ the concept and efficiency of the Cinelerra interface, but the GUI is ugly, hard to read and feels needlessly foreign in places where it could easily follow the conventions of common Linux apps (e.g. GNOME / KDE human interface guidelines). This is about much more than looking pretty, it truly is about usability and following interface conventions. I think there is a lot of low-hanging fruit that Cinelerra could pick relatively easily. It wouldn't be necessary to change toolkits or anything. Mikko ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On Wed, 2007-15-08 at 21:20 +0300, Mikko Huhtala wrote: Christian Thaeter writes: This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV [ ... ] 2) Stop using SVN [ ... ] 3) Make releases [ ... ] 4) Make tracking HV less important Just gently to put my oar in again, I guess there are some good motivations for doing this, although I liked the black nature of the interface and thought it looked very professional from the start, and any of those changes are in the future, I understand. I just wonder if this might involve the demise of Cinelerra if you start a massive rewrite of the program, decoupling it from HV, then what happens to the CV version of things? Does it end here? Why not write a separate Video Editor with a *new name*, if it's going to be so different in structure and allow the current Cinelerra to continue, both HV an CV. I've come to like it and I fear that you might not get enough coders to successfully develop the new version and we'll wind up with lots of half developed lines none of which function well if at all and no really good freeware video editor. Maybe I'm seeing this wrongly, but it's just the impression I get from reading the recent posts,... like I've seen this scenario on other projects and it usually ends up badly, not always, of course. Just a thought. Hear hear. I've been reading this thread and this is precisely what I would have liked to have said, but I'm not a developer so it's not my place to say. But even to an outsider, it seems that both communication and code exchange with HV is much, much too infrequent, and that this is holding things back. Well, that could be. snip I _like_ the concept and efficiency of the Cinelerra interface, but the GUI is ugly, hard to read and feels needlessly foreign in places where it could easily follow the conventions of common Linux apps (e.g. GNOME / KDE human interface guidelines). You mean like putting preferences under the edit menu and stuff like that. Yes that would be progressive. This is about much more than looking pretty, it truly is about usability and following interface conventions. I think there is a lot of low-hanging fruit that Cinelerra could pick relatively easily. It wouldn't be necessary to change toolkits or anything. Could be nice, but is this what is falling under the category of human interface, which won't be touched for a couple of years. Fine, it can be good to get requests in early, but they may not remember it by then. Good ideas, though. -- Warmest Regards, Fred Williams ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
mark carter wrote: On Wed, 2007-08-15 at 19:36 +0200, Christian Thaeter wrote: 2) Stop using SVN I just saw a YouTube vid by Linus who is talking about git: http://uk.youtube.com/watch?v=4XpnKHJAok8 Even if commit access is generously handled to people who ask, it's still a big blocker as I explained earlier. As long we have only one linear history everything has global impact and there is no easy way to add new features without running in troubles. There is no easy way that small groups of people try and review new features, no easy way to get good but intrusive new ideas back into CV. I think the problem is that there's a lot of good code out there that isn't making it into the main tree, for want of a better word (and no, I'm not necessarily thinking of my code). Actually, I think the problem is only partly to do with it being in SVN and not in GIT. I think the main problem is lack of modularity. Without sufficient modularity, GIT can't help much. For example, I might even suggest (radically) that the plugins shouldn't even be in the git repository. People who want to write plugins should make their own repos consisting only of the plugin they want to submit. People developing the core of cinelerra wont even care about the plugins. Users can just download the plugins they're interested in, from whatever place they are available, and use those. Maybe packagers will come along and bolt the cinelerra core together with the plugins. It can go further. Take file loading. If file loaders were plugins, then that would be another that could be separated out. For cin3 we will do it this way, using the brand new git-submodule support which will become useable really soon. When it is time, detailed instructions will follow. For cin2, using git will just enable that someone sets up this infrastructure (I thought about doing this with the docs first, working together with raffa sometime next). You won't be able to propose / show such radical things on the SVN, git is just a enabler for this. The problem I see is that this has 2 parts 1. The modularization on the repository level, which is doable. 2. Tear the current sourcetree apart to modularize things, which has impacts on dependencies and build system setup. For the plugins that would be easy since they have already their own subdirectories, for filehandling and codecs this may involve quite much work and refactoring. What I'm saying is that in order for git to work, you have to have separate subsytems - with well-defined interfaces, of course. Thats one of the reasons which motivate cin3. I started to refactor cin2's sourcebase which seemed just to be a bottomless pit. I could be misunderstanding how git derives its strength, though.But I think the problem we're seeing is a lot of forks that don't stand much chance of being propagated to the main branch, which I think is a shame because it means that a lot of good effort has gone to waste. The question is who is responsible for deciding what goes into the main branch or moreover what defines a main branch. We need to change our goals first and define what has to constitute CinelerraCV releases and then think about some way how we work together to get the stuff in place, distributed revision control would be only a tool providing us the ability to reach this goals, but not make decisions about the project direction, thats clear. And thats exactly why I created this mob repository and my 'ct' branch, to free developers from the constraints that there is a stalled SVN branch with no much perspective to get things merged. Finally we have at least some discussion how to work this out, maybe really soon we can agree on some process how we assemble releases, maybe we just happily merge from each other and meet again in a few months and decide/vote what should go into a official release, or we nominate a Release Manager among us who is responsible to prepare the next release, or we use some shared git repo where anyone can push changes which will be blessed official and reviewed with the goal of a releaseable state. How we decide to do it lies in our hands, after all I try to push us into a Just-Do-It direction, we could talk endlessly about it, as long the current centralized branch is there, we will stuck to discussions with no progress. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
On 2007-08-15 17:36, Christian Thaeter wrote: This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV 2) Stop using SVN 3) Make releases 4) Make tracking HV less important I've been pretty silent on these issues so far, not wanted to put a damper on new ideas and contributions, but looking at all the ideas makes me think you should really consider a true fork. You've proposed: * Changing the project goals * Changing the project tools * Redesigning the core of Cin * Rewriting the core of Cin I think you won't get much feedback from the older core developers since these goals are so large and you haven't tackled a smaller piece of Cin first. The other thing that comes to mind is that you shouldn't co-opt the Cinelerra name for a new project (Cinelerra 3) if Adam does not contribute a reasonable portion of the code. It is, after all, his video editor. As the Cinelerra 2 code base is GPL, you can certainly use portions of it for a new design with attribution to Adam. The amount of work proposed for the new project is not unlike the scope of a project we presently have running at work. It's probably a 10 year project until completion. I suspect the core contributors are not thinking about a full rewrite at this time. I'd like to hear their thoughts also, of course. -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] WHERE CINELERRA IS GOING? ...anyone? proposal for CinelerraCV 2 maintenace
Kevin Brosius wrote: On 2007-08-15 17:36, Christian Thaeter wrote: This my maybe arguable view how to hive Cinelerra CV out of its develoment stall: 1) Change the focus of CinelerraCV 2) Stop using SVN 3) Make releases 4) Make tracking HV less important I've been pretty silent on these issues so far, not wanted to put a damper on new ideas and contributions, but looking at all the ideas makes me think you should really consider a true fork. I think declaring this a true fork would be contraproductive, my least intention is to divert the cinelerra community, I wan't to get some new drive where people are motivated to contribute. At some extent, this will only work if the Community supports this (if not, fine, stay where you are). Yet alone the discussion started now may hopefully yield some result which leads to little progress. You've proposed: for current CinelerraCV: * Changing the project goals * Changing the project tools As new project: * Redesigning the core of Cin * Rewriting the core of Cin Take this as 2 different things which don't depend on each other and could happen each one alone and in parallel. I think you won't get much feedback from the older core developers since these goals are so large and you haven't tackled a smaller piece of Cin first. I have done little work in my branches but get demotivated by this 'bottomless pit' discovery and that there is no much perspective to get new things merged into the SVN trunk because it breaks the current concept. I think thats exactly what many other potential contributors see. There are patches and contributions rotting somewhere. The other thing that comes to mind is that you shouldn't co-opt the Cinelerra name for a new project (Cinelerra 3) if Adam does not contribute a reasonable portion of the code. It is, after all, his video editor. As the Cinelerra 2 code base is GPL, you can certainly use portions of it for a new design with attribution to Adam. I agree that we could only name it Cinelerra 3 when Adam supports this decision. We will certainly reuse some of his code and I have the hope that he contributes/joins the efforts somehow/sometime, but thats really up to him and I don't want to make guesses unless he speaks out. So far we would like to name it cinelerra 3 because out intention is to create the next incarnation of cinelerra and not just another video editor. The amount of work proposed for the new project is not unlike the scope of a project we presently have running at work. It's probably a 10 year project until completion. I suspect the core contributors are not thinking about a full rewrite at this time. Well, then think about it. I know that this is a massive task for the next few years and we won't or even can't do it alone without support and help from the rest of the community. I'd like to hear their thoughts also, of course. Me too, well I can only stress that this might be started by a few people as now, giving it a seed and motivation, but it will require the experience and involvement of more people in future to become a success. Christian ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
