KDE Frameworks Release Cycle
ps_ml at gmx.de
Thu May 8 22:13:48 BST 2014
-----BEGIN PGP SIGNED MESSAGE-----
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
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
If these are _fixes_, why are they not backported to the stable branch
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the kde-core-devel