[Kdenlive-devel] Kdenlive future (preparing Randa)

[Evert Vorster]

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