KDE Frameworks Release Cycle

[Saro Engels]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Am 04.05.2014 18:36, schrieb David Faure:
> [Cross posting against my will...]
> 
> On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote:
>> I understand that the big concern was about the testing: stable
>> branches did not receive the same attention
> 
> This is not the main concern.
> 
> My main concern is that application developers prefer to work
> around bugs in KF5 (previously: kdelibs) rather than fix things at
> the right level, because "fixes in KF5 will only be available in 6
> months, and I want the bug fixed now".
> 
> Your suggestion (6-months "stable" release) brings us back to
> exactly that.
> 
> We'd like to try something better. Monthly small increments. Never
> "big" changes that break things, they get cut into small increments
> too. So no reason to buffer changes for 6 months.
> 

One thing I want to mention here because I think there is no real work
around:
When will you add new dependencies?
In a rolling release process this is possible every month. From a
packagers point of view, this is hardly doable:
You cannot accept new dependencies in a security update.
So what is the solution for the packager?
Probably make a branch on top of the release that was used first, and
try to find as many bug fixes as possible that will still apply.

While rereading your email I see the following thing:
"fixes in KF5 will only be available in 6 months, and I want the bug
fixed now".
If these are _fixes_, why are they not backported to the stable branch
atm?

Maybe we should fix another issue here, and instead modify our
understanding of stable branch. Even if it is hard for me, the
maintainance of the Linux Kernel could be an example: with clear
maintainers (or teams) of branches which will check which issues need
backports. I think this is also the way it would happen (distros would
probably try to maintain stable branches together), so I'd prefer if
we could plan this ahead of the first release instead and possibly
involving the developers of the libraries.

regards,
Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTa/OHAAoJEPAKI6QtGt1xyGoP/3mjMSidWSYy0jyw53Gl+ksW
FWGeYU9drfo253iR+DemaiD3VSa6vOgdKl2RK03dpdM1GaKl2Hhpls/HcbucmCza
7vUa+IqjDiaFWLWtEn95ktRTCmbPHCGB87G1D9m7KrVmBqVHwVtIbkn3myXdPRR8
4fq1e4sPid020QGZNL6WoGqbYFePeFEf8rLu7pyNUTvE3mJsqSsXHDUKfCeDzW1a
epxiheJxgCsz99GwQbvY7w3E3ge1I36jDlnCfCSwWoUbZe+uFU+wRD5fxtCDQcyE
rkpy9IV4uzqFhloNI0wnTXrfBjME+b15uDDWCQBDGczWx6nJIS/ie7tI8BHNh8lf
q2xdviVaBvgDCgjYjf5vxYr+HnO4LiRT5mZktCtjDbNEjAfhuOos5fLVqDFXXT3j
oJUtmn7pxqM/0rrTTExRXtdKN8pz/bHdciOlo8I4T/j+bVn4Sd7MQFJE4DYmsfa3
/ZZW63dgbUbRHEBFl3hjLQ3NtB1nk+YHlhwi89VB1yBmi8M5MVQDazkxhpygrPJC
K/JWRYfbar2dJSjZiQl0psl5ieJB/6+CL+sHK/36FGht1Otrx+rUAY+Km7oCxYy+
l9vzPd2CgL7LQHRxRxbEgRrNlSq0zrqApxUmau5sJsW9HoinOUvUvSr7qXQczPQB
wyo3Djyu0lKuS8227eoV
=LbgL
-----END PGP SIGNATURE-----