Fwd: KDE Frameworks Release Cycle
ervin at kde.org
Mon May 19 13:18:49 UTC 2014
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
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
Did I miss any other concern?
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the release-team