Fwd: Re: Fwd: KDE Frameworks Release Cycle

[Scott Kitterman]

On April 30, 2014 6:26:14 AM EDT, "Àlex Fiestas" <afiestas at kde.org> wrote:
>On Wednesday 30 April 2014 12:04:15 Raymond Wooninck wrote:
>> On Wednesday 30 April 2014 11:28:26 Àlex Fiestas wrote:
>> > Having a release every month will allow distributions to package
>fresher
>> > versions of frameworks since we will virtually remove the
>synchronization
>> > problem.
>> > As an example, Opensuse released 13.1 with KDE 4.8.5 iirc, which
>already
>> > had no support from upstream. You had to do that because our 6
>months
>> > release schedule did not synchronize with yours. Having releases
>every
>> > month fixes the problem.
>> 
>> Sorry to say, but this is bullshit.  13.1 is the current openSUSE
>distro and
>> was shipped with KDE 4.11.2.  We provided maintenance updates based
>on
>> 4.11.3, 4.11.4 and 4.11.5.  At this moment we are even shipping the
>> kde-workspace releases as maintenance updates.
>I said "iirc" which stands for "if I remember correctly" which
>apparently I 
>did not. Sorryf or that.
>
>Here you have the link to the release that released with an almost "out
>of 
>support" version:
>https://en.opensuse.org/Archive:Features_12.2#KDE_Plasma_Workspaces
>
>As you can see, the link shows the features of OpenSuse 12.2 featuring
>4.8.4, 
>our last 4.8.X release was 4.8.5.
>> Yes, a distribution release cycle might not match with the KDE
>upstream
>> release cycle, but that NEVER put us in the position to ship an older
>> unsupported release.  For every distribution release the openSUSE KDE
>> Community team validates both release cycles and then we set a target
>> version for KDE.  e.g. for the upcoming openSUSE 13.2, the target is
>to
>> ship it with KDE 4.14 as that this is the latest official release of
>KDE at
>> the moment of the openSUSE release.  Whether this will be 4.14.0,
>4.14.1,
>> ...  doesn't make that much difference. After the openSUSE 13.2
>release we
>> will provide maintenance updates based on the 4.14.x releases.
>So, you will not simply update to 4.14.X but instead do cherry-picking
>of the 
>bug fixes? Because that would be the same with Frameworks.
>
>> The issue is that non-rolling distributions sets a stabilisation
>period
>> before the official release. This means that the version that will be
>> shipped needs to be in about 2 months before the official release.
>From
>> that point forward only bugfixes are allowed. In the past this was
>achieved
>> for KDE by making sure that at least the Beta version or preferably
>the RC
>> version of the upcoming KDE release was in at that moment. This
>didn't mean
>> we would ship Beta or RC, but we knew from that moment no more new
>> functionality was going to be added and therefore we would adhere to
>the
>> stabilisation period.  This will all be gone with the proposed
>Release
>> Cycle for KF5.  Based on this we know already that non-rolling
>distro's
>> will ship an actually unsupported KF5 version due to their
>stabilisation
>> period. For openSUSE this would mean we ship an 2 or 3 months old
>version
>> of KF5 with a lot of back-ported bugfixes.
>> 
>> So in my book this would make the synchronisation issue bigger and
>NOT
>> virtually remove it.
>> 
>> > Also ideally, we should break with this tendency of
>"upstream/downstream"
>> > and you should become upstream, I would love to see opensuse (and
>others)
>> > keeping the release you picked maintained in a branch.
>> > Even going further, you could (and I think you should) release
>point
>> > releases of that Frameworks version.
>> 
>> In other words what you imply here is that KF5 upstream will focus
>just on
>> the master branch and that distributions should setup a maintenance
>branch
>> and maintain that themselves. If this is the goal, then this should
>be made
>> clear from the beginning. In my opinion this would add to the mess as
>that
>> we would end up with a branch per distribution. And what would then
>be the
>> difference by having those patches in our distribution packages ?  I
>> believe distro's are already collaborating in a good manor regarding
>> sharing patches, etc.
>The difference is that you will do proper testing with all the QA in
>place on 
>each distros, we don't have such thing "upstream" beyond the tests.
>
>As for the mess, each distro picks their version as you said and you
>(as in 
>distros) already do backports and cherry-pick patches, nothing new.

A certain amount of it isn't new.  What's new is upstream abandoning each release as soon as it's out the door. 

We push all the maintenance updates too.  After a certain point we are on our own, but with KDE SC there has been a good level of support for from upstream to get things in good shape. Now it's all going to be on us.

Scott K