Hi all, First, thanks to Till for posting news and writing about sprint fundraising. (would it be possible to give some money we got from our previous campaign to this event, as the goals are related?)
I'd like to start a little brainstorming (share my hesitations) about where to go with the code from now on... We have the "next" branch, remaining stable but not evolving (no new functionality). I'm trying to give more time to help users solving their bugs, but don't find it exciting to work with an old code base (=rather messy) and staying far behind multimedia evolutions. We have the "refactoring" branch, hard work from Till relayed by JBM 2 years back, seen then as a necessary restart from scratch for a healthy future. >From my point of view, it stopped to evolve far from the functional state; the huge task left to equal the features of the 10-years old v0.x series seems discouraging. However it would be sad to loose the good ideas and the great coding effort. We have the "master" branch, that switched to OpenGL & multithreading for all rendering tasks (targetting Movit filters). The move is incomplete, leaving the program hardly able to start or very unstable then. And from my understanding it seems the changes did not occur in a very good place, the transition could have been much smoother. But again I wouldn't like to throw away several weeks of work that where bringing highly interesting progress. We should have a "frameworks" branch, to start using Qt5 & KDE Frameworks, and avoid going towards computer museum. And there is Shotcut, that I find is a very good basis for a future Qt5 video editor, well organized and written. As it claims, it is still incomplete, features and user-friendliness still well behind Kdenlive, but it evolves at a much better pace than our project (not a hard point :-/). So my question is : should we (me at least)... - start my own fork from stable, trying more progressive evolutions (refactoring, GLSL, KF5) : ideally it would never break from one git push to the next... - try to understand and fix the divergences in master (already did unsuccessfully...) - start from a new base with refactoring - go to a new base : merge efforts and contribute to Shotcut, importing the features and UI elements we liked in Kdenlive (if Dan and others agree) In any case it seems we would have to wait for quite a long time before we could release a version with new features (if we don't receive an exceptional new amount of energy - maybe in Randa?) A side question is about our organization : as we work openly and with few manpower, "master" branch remained unusable during several month twice last years (and so rolling packages like the ones from dev PPA or Arch). how could we enforce the "work in a branch" rule, balancing with the need for help and visibility (testers => packages)? should we go through a review process before merge into master? recommended for quality, but who has time for this? I don't feel enough skilled to legitimately accept or reject complex contributions (I can mostly be a first tester, is it enough?) Please share your opinion (and sorry if I expressed anything in a wrong way, I don't want to harm anybody) BR, Vincent. ------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel