[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:       Raymond Wooninck <tittiatcoke () gmail ! com>
Date:       2014-04-30 10:04:15
Message-ID: 1894523.kyYvP65yOJ () hqvmt4xx20 ! eur ! cchbc ! com
[Download RAW message or body]

On Wednesday 30 April 2014 11:28:26 =C0lex 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 an=
d =

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. =


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 versi=
on =

for KDE.  e.g. for the upcoming openSUSE 13.2, the target is to ship it wit=
h =

KDE 4.14 as that this is the latest official release of KDE at the moment o=
f =

the openSUSE release.  Whether this will be 4.14.0, 4.14.1, ...  doesn't ma=
ke =

that much difference. After the openSUSE 13.2 release we will provide =

maintenance updates based on the 4.14.x releases. =


The issue is that non-rolling distributions sets a stabilisation period bef=
ore =

the official release. This means that the version that will be shipped need=
s =

to be in about 2 months before the official release. From that point forwar=
d =

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 goin=
g =

to be added and therefore we would adhere to the stabilisation period.  Thi=
s =

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 KF=
5 =

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 cle=
ar =

from the beginning. In my opinion this would add to the mess as that we wou=
ld =

end up with a branch per distribution. And what would then be the differenc=
e =

by having those patches in our distribution packages ?  I believe distro's =
are =

already collaborating in a good manor regarding sharing patches, etc. =


Raymond
_______________________________________________
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]