[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
From:       Michael Pyne <mpyne () kde ! org>
Date:       2014-05-01 0:03:55
Message-ID: 1821952.ObTCAhZQaK () midna
[Download RAW message or body]

On Wed, April 30, 2014 15:51:56 =C0lex 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 o=
r =

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 t=
he =

packages play nicely together when bundled together into that coherent whol=
e.

We ensure coherence of the frameworks as a whole, generally at any given po=
int =

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* h=
ave =

tested it to. I do not think it is surprising that distributions do not wan=
t =

to take on that type of package maintenance burden, or that distributions d=
o =

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 th=
ere =

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 guaran=
tee =

with stable branches and freeze periods between tagging and making tarballs=
. =

Are you sure that new frameworks releases won't have new library dependenci=
es =

not already present in that distribution's baseline?

I do think that any given framework will be that much more likely to integr=
ate =

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 ma=
ny =

3rd party libraries with their source release to guarantee integration, whi=
ch =

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 distro=
s =

(say, every 2 months)? Or would even this be too much work?

Regards,
 - Michael Pyne
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]