Fwd: Re: Fwd: KDE Frameworks Release Cycle

[Àlex Fiestas]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20140430/e56f512b/attachment.sig>