-----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----- _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
