[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
From:       Scott Kitterman <kde () kitterman ! com>
Date:       2014-04-30 11:50:02
Message-ID: c078b56b-f80b-4f06-8103-e779a579c30c () email ! android ! com
[Download RAW message or body]

On April 30, 2014 6:26:14 AM EDT, "Àlex Fiestas" <afiestas@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

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]