Hi there. I am just a user of Kdenlive, and I do want to thank all the coders for all the hard work on this great video editor.
I report bugs to Mantis, with any workarounds as I find them. As I am not a coder, I cannot appreciate the implications of a rewrite versus a refactoring as far as the amount of work involved. >From a user perspective, though... I think a refactoring is better than a rewrite, as the project stays usable while the changes are happening under the hood. Also, since the code is rather messy, it might be an idea to do the housekeeping first. I thought that a refactor would achieve both cleaner code and make bugs occur less often. Once the refactor is complete, adding new features or frameworks might be a lot easier. Again, thanks for all the hard work, Kdenlive is a great video editor! -Evert- On 25 June 2014 22:01, Vincent PINON <vincent.pinon at laposte.net> wrote: > 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel -- Evert Vorster Chief Observer WG Cook
