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