Fwd: Re: Fwd: KDE Frameworks Release Cycle

[Michael Pyne]

On Wed, April 30, 2014 15:51:56 Àlex Fiestas wrote:
> So, I understand that for big releases you wouldn't trust us on "no
> regressions", but please take into account that these releases will be a
> completely different monster.
> 
> Finally, could you (or any packager with similar concerns) explain to me
> which reasons (apart from policy) would make you not comfortable releasing
> this?

I can't speak for them, and the list of problems with our current release 
policy you have given is on the whole accurate as far as I can see.

But I think the problem (besides policy) is that the addition of features or 
major changes would invalidate the integration and testing work done by the 
distribution itself. The distribution packagers are not simply trying to 
package up software and send it "over the wall" to the build infrastructure to 
be signed and eventually burned onto an .iso. They also have to make sure the 
packages play nicely together when bundled together into that coherent whole.

We ensure coherence of the frameworks as a whole, generally at any given point 
in time. The problems raised by our packagers is that even if they want to 
give us a policy exception and rely completely on *our* guarantee of 
integration testing, that guarantee only extends to *all* of frameworks at 
that given point in time.

In other words, let's say we release Frameworks 5.11. A non-rolling distro 
based off of 5.9 would have to upgrade *all* of Frameworks, as a complete 
bundle, to 5.11 if they wanted to integrate a single package.

Even a simple KF5-using application that only uses KCoreAddons (a Tier 1 
framework) would necessitate the upgrading of all installed Frameworks, no 
matter what Tier they are in.

And even if they do that, that only gets the quality up to the level *we* have 
tested it to. I do not think it is surprising that distributions do not want 
to take on that type of package maintenance burden, or that distributions do 
not necessarily trust us (with our noted manpower concerns) to release 
packages where a Tier 1 package could be at 5.16, Tier 2 at 5.15, Tier 3 at 
5.13 and a user-compiled application built against Frameworks 5.12, and be 
able to trust on our processes alone that this would work.

This is a pathological example, but it is the guarantee we give, and the 
guarantee we're now asking distributions to accept. As far as I can tell there 
are at least 55 separate frameworks at this time. Are you *sure* there are no 
ways to inadvertently cause breaking bugs in any valid combination of these 55 
frameworks when we're adding features? It's hard enough to make this guarantee 
with stable branches and freeze periods between tagging and making tarballs. 
Are you sure that new frameworks releases won't have new library dependencies 
not already present in that distribution's baseline?

I do think that any given framework will be that much more likely to integrate 
well with the process of the new release cycle. And distributions should 
already be updating KDE packages en masse to avoid the problem of having 
things like kdelibs 4.11.5 and kde-runtime 4.11.4 around at the same time.

But the addition of new features, translations and even library dependency 
changes is a much different proposal than we've offered before. What's more, 
the 2 major pieces of software that do get exceptions do so by including many 
3rd party libraries with their source release to guarantee integration, which 
is something we can't get away with, and they have a much more focused task. 
Is it fair for them to complain (and they're *all* complaining AFAICS).

I would like to use the new release cycle because it solves the many 
acknowledged issues with ours. Is there a way to get the "best of both 
worlds"? Maybe have a stable branch that is reset every 6 months and which we 
frameworks maintainers can cherry-pick bugfixes into for non-rolling distros 
(say, every 2 months)? Or would even this be too much work?

Regards,
 - Michael Pyne