[Kdenlive-devel] Kdenlive future (preparing Randa)

[Vincent PINON]

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.