Fwd: KDE Frameworks Release Cycle

[Scott Kitterman]

On Monday, May 19, 2014 15:18:49 Kevin Ottens wrote:
> Hello all,
> 
> First of all, my apologies for the long time taken for me to send an email.
> 
> So, this release cycle proposal generated more debate among our dear
> packagers than we anticipated. I tried to keep up with the thread, but too
> be honest it's far too long at that point and also the discussion went in
> unproductive directions (e.g. some proposals were made and understood as
> official while they're not on the table at all).
> 
> I think the problem with that discussion is that most people taking part in
> it are either clueless about the packagers constraints or the developers
> constraints (and hopefully not both ;)). People knowing both sides of the
> job are a rare breed.
> 
> I suffer from that same flaw... I don't know much about the distro
> constraints. Still, after seeking counsel in our rare breed pool, I'll try
> to start over from the initially forwarded email and hopefully address some
> of the concerns (I doubt I'll address them all though).
> 
> To me it seems like we have two different set of packagers here, depending
> on the policy their distribution is applying:
>  1) the ones who don't upgrade package versions when they froze for their
> next distribution release;
>  2) the ones with a slightly less strict freeze where they are allowed to
> upgrade to bugfix versions only.
> 
> I will try to address both cases separately.
> 
> 
> # Case 1: Strict no version upgrade
> 
> For that case, the problem is that packagers of those distributions were
> still allowed to pull in single patches in their packages. Each patch could
> then get approved or rejected for distribution consumption. In turn, the
> release branches were the place where packagers could look for patches.
> With our change in the release cycle and the removal of branches, we are
> robbing those packagers from their source of patches.
> 
> To me it looks like something easy to address. I propose (IIRC it was
> mentioned somewhere in the thread) that we mark the relevant commits with a
> specific keyword to make it easier for packagers to shop for bug fixes on
> top of the version they have in their packages. In fact, we have just that
> already in the "BUG" keyword. So it would be a matter of extending it to
> improve the communication by being more precise. We could add a
> "CRITICAL-BUG" keyword. Would work the same way than the other one, but
> could be used for important "eat your data/cpu" type of issues. Next to
> that we should introduce a script to extract a list of patches having those
> keywords since a given release.
> 
> It's probably a nice way to communicate with our downstream. I even think
> it's better than before as it makes things more explicit.
> 
> # Case 2: Bug fix version upgrade allowed
> 
> That case is kind of trickier. The first group released outdated versions
> with patches on top, and now they would release outdated versions with
> patches on top... No big change in the end, it is more a matter of giving
> them a way to get to the patches. For this second group, it is another
> story. They bumped versions because they contained only bug fixes and we're
> planning to not provide that anymore and so they will not update anymore.
> 
> This reaction is mainly based on the belief that our new releases will be
> less stable than bug fix releases (I think there's an extra factor I'll
> address in the next section for simplification purposes).
> 
> Going forward I see four options for addressing those packagers:
>  1) Don't care, which means we're pushing them toward the case 1, they'll
> release outdated versions with hand picked patches on top;
>  2) Gain the necessary trust of our downstream to show that our new releases
> are not less stable than our former bug fix releases;
>  3) Provide a yearly LTS branch as I've seen proposed;
>  4) Provide release branches for which we commit backports.
> 
> The problem I see with 3 and 4 is that it's mostly going back to what we had
> previously. We'll end up with the same lack of testing in those branches
> that we have today, and we'll see no reduction in the number of developers
> treating the frameworks like a black box.
> 
> So, even though I understand why it wouldn't please packagers, I don't think
> we should change course overall. So the tactic we'll follow is (1) hoping
> to get to (2).
> Indeed, if we don't change course, I expect the distributions will all move
> to a scheme of backporting. That's unfortunate, but hopefully, we'll manage
> to gain the required trust to prove that the releases are not less stable
> than the former bug fix releases. for those distro which upgraded on our
> bug fix releases to in the end upgrade on our new releases too (probably on
> their own cadence though). If they end up not being less stable, it
> shouldn't make a difference and the distributions which upgraded following
> our bug fix releases should be confident enough to upgrade again.
> 
> # Extra consideration
> 
> I mentioned above that "not upgrading" was *mainly* based on the "it will be
> less stable" belief. But from what I gathered from the discussions, it
> seems there's another factor hidden behind that which is dependencies.
> Indeed, adding or upgrading existing dependencies is disruptive downstream.
> 
> So I propose the following policy:
> We can add dependencies anytime *but* they can only be optional. We can only
> depend optionally on newer versions of existing dependencies. Those newly
> introduced dependencies can be turned to required dependencies only twice a
> year (january and june releases).
> 
> This policy can probably be enforced by some automated means. We could
> probably have the CI build our frameworks both with the latest dependencies
> needed and with the allowed mandatory dependencies only.
> 
> I think that with that dependency management policy and the proposal about
> tagging backportable commits, it should allow to ease the pain for our
> downstreams quite a bit while retaining most of the intention of the coming
> release cycle.

Speaking as a packager for a distro that's in group #2, I don't see this as 
any change from your initial proposal.  

I think you still don't understand.  KDE libraries (to be KF5 in the future) 
is one very small part of a distribution with tens of thousands of different 
binaries.  KF5 is just not going to get special cased to ship feature releases 
as post-release updates.  Your hoped for "Gain the necessary trust of our 
downstream ..." isn't going to happen.

With a handful of exceptions, the reasons for don't relate to KF5 at all, such 
exceptions aren't given.  Period.  It doesn't matter what is more stable or 
not.  Feature releases aren't getting in.

You're proposal moves us into group #1 and if there are upstream complaints 
about stuff being out of date, you get handed a mirror to look at.

Scott K