Fwd: KDE Frameworks Release Cycle

[Kevin Ottens]

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.

Did I miss any other concern?

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20140519/336ba433/attachment.sig>