KDE Frameworks Release Cycle

[Luigi Toscano]

Kevin Ottens ha scritto:
> So, we had a team discussion here with Albert, Aleix, Alex, Alex, Aurélien, 
> David, Rohan and myself. We juggled with several options, trying to address 
> the following constraints:
>  * We don't have many contributors;
>  * We don't have enough testing in the stable branches, developers tend to 
> have a hard time to dog food those;
>  * We don't have enough contributions coming from the application developers 
> because it takes a lot of time for them to benefit from their changes so they 
> tend to workaround instead and consider kdelibs more and more as a black box; 
> going forward we don't want that for KDE Frameworks.


So, I've seen no discussion about this (not on this list, I think it's going
on somewhere else) but I would like to rise my concerns with this decision.

It can increase the "balkanization" of the version shipped by distribution.
This is going in the opposite direction of the advocated "give users a real
KDE experience". With no stable branches, distributions will have to randomly
choose one branch to stabilize and the risk is that based on their schedule,
they will choose different versions, heavily patching them (_more_ than what
happens today, where there are few synchronization points).

Other big projects with frequent releases, like the Linux kernel or Firefox
have stable branches too; not all of the releases, but some of them. Firefox
had to provide a "esr" version (long support, one year) because it's not
really possible to update an entire stack in long-term supported
distributions. And Firefox is mostly a leaf in the dependency tree (with the
exception of libnss and libnspr, which can break and broke in the past from
one esr to another); here we have an entire bunch of "core" libraries (as in
Linux with its long-term branches).

I understand that the big concern was about the testing: stable branches did
not receive the same attention, but I think that killing them is not the
solution; solutions include an increase number of automated tests (unit,
integration, scenario) as first step, and a bit of time invested in the rest
(manual) testing, with contribution of distributions but not only them.
We had a lot of coding sprint, we can organize test sprints as well (which
benefits also the main master branch, of course!)

I also think that many frameworks will stabilize after the initial rush, so it
will. I suspect (just a feeling, not backed by any fact) that Tier1 will
stabilize sooner, Tier3 will have more moving part (please note that this is
not about ABI/API, which I'm sure will keep the compatibility as it was
before). If this is true, it could help in creating "naturally" stable
branches; KDocTools is a good example, it's unlikely to have new important
changes too frequently, but I guess it will be the same for KI18n and others.

Minor point: the original statement of "three releases" for Porting Aids
should be fixed to be time based (I guess at least 6 is not 9 months).

So, my proposal(s).
I think that some kind of long term branch branch is needed. It could be an
yearly release (and we could do a testing sprint for that, solving the problem
for the "love"), or a bit more frequent, like twice a year (no more!); still
at least one release could benefit from a sprint. Collaboration from
distribution is needed, so that they can coordinate. In case of yearly
releases, if few distributions want to have an official stabilization branch
(like in Linux) they will able to create and manage a special branch (with
some input from developers).
After the initial rush, revise the release schedule in the light of the
"stable" frameworks, maybe they can be "naturally" on a stable branch (because
no big changes will land in them).
Possibility for opting out from the monthly releases for individual frameworks
(i.e. still released with the bundle, but no monthly changes). I'm wondering
about going this way on KDocTools.

Ciao
-- 
Luigi