--===============5309685474822295662==
Content-Type: multipart/signed; boundary="nextPart6123662.vQDHrp1F4u"; micalg="pgp-sha1"; protocol="application/pgp-signature"


--nextPart6123662.vQDHrp1F4u
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Wednesday 30 April 2014 10:41:30 Raymond Wooninck wrote:
> For openSUSE it will definitely bring problems as that we wouldn't be able
> to release any maintenance updates anymore for the KDE Desktop with this
> Release Cycle.  As Sune indicated, if KF5 is updated then the other
> components like Plasma-Next and the Applications needs to be rebuild. This
> is not the current setup of the openSUSE maintenance process, nor will this
> change just for KF5. This means that the only way for us is to start
> back-porting the bugfixes and release those as maintenance updates in order
> to provide a stable experience for our users.
> 
> If the other components would select a similar Release Cycle, then this
> would mean that the non-rolling distro's have to focus on a constant
> back-porting of bug-fixes and we would not provide our users with newer
> functionality.  This would eliminate the main goal that this Release Cycle
> is targeting (To introduce new functionality gradually) as that the main
> distributions would skip several KF5 releases before a new distribution
> version is released to the users.
This is not totally true, let me explain.

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.

As for the backporting, you could use bugzilla (even via api) to get a list of 
everything that has been fixed, get the SHA and backport it automatically, that 
will ease a lot the process.

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.

--nextPart6123662.vQDHrp1F4u
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAABAgAGBQJTYMI+AAoJEGCsZ2zsJAWe5nMP/jvgk5/ylVX/NOqD3udptYBC
FUGNtNxfB1Js61Ew2phClviY4M8fKXkP0gXAFprT9KyaUTXyjV+s38JHy9sLBJdh
+hM19Cy+jiWuYuwTCm7PXuIyQ6RJwMQwN5/HtQqre3mIV2ppzwnYDJgpgSrmR3FS
g3D1Q4c6+QZLy3ycHutQwt1B17mF8NhSoNLEiZcBSm4mipRuVbNdIDbzPp5c2vaR
JbBXieQlBCIPI8jneLkV3mork14be6miaU/fEtG02WHeBUS7bDXga/D/n2M4jPQO
n/MDPmmVhLYYq/YslYMb0j0d0qeNZqX2SuTH0PWYG1hUPvTg+WdDeMZe9Dvfv8nN
u491X5EV0xm0BWk3bfnoUdQmkpQTV4IX/ARYAscaRcrnZktHkd4dmC1uzQNvqCNs
wy8Udsn/x2TJMByP/bHaBYpXZFKQDqg7oG4XKg471yW+FP1ENtPYBZtHWr80hPZN
3ErH6pA+C65/TA4W8pHsllu85XGtVtAuPF3MlLhWWemnl09xEPBna99bXlJ5r9IL
XYdxv8UjK3n1RWqAJkP+N4l2++Efr/WSHPF8d8JAegRcpR6ueIxsjZJXK0wXjL4N
E7TgBfyUACIkLXhVLuOYqNTHpY9e99BTP812uaSX+bLymr2oAfUkiDPlK/QYZIMi
FhnR+s0pf2ALCIxiDAwe
=qnw2
-----END PGP SIGNATURE-----

--nextPart6123662.vQDHrp1F4u--


--===============5309685474822295662==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============5309685474822295662==--