Proposal unify back our release schedules

[Kevin Ottens]

Hello,

Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker here I 
think. I'll try to add a couple of extra aspects to feed the thinking on this 
topic.

On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote:
> I know this might be a controversial idea, but I would like to propose
> reunify our release schedules. I feel like splitting our releases schedules
> between Frameworks, Plasma and Gear is not working as well as we intended
> it to be when we split the releases schedules for Plasma 5. This is for
> multiple reasons:
> 
> * We end up with 3 different products which are released at different times
> but are connected together. Apps and Plasma both need Framework, Plasma
> needs some packages from gear like kio-extra, Gear needs some package from
> Plasma like Breeze. Coordinating all these inter-groups dependencies is
> complex and was one the reason we had to do a megarelease for Plasma 6.
> Also for the end user, one product is a lot easier to understand.

This is an engineering topic in this case.

And, to me, this is an excellent reason not to reunify release schedules! 
Because what it tells me is that we're still having dependency issues which 
need to be solved.

The example you give shows Plasma depending on Gear, this shouldn't happen, so 
I'd argue: let's fix that instead.

Aligning the release schedules would only hide such structural issues.

This was one of the main engineering motives to split things up: when it 
wasn't splitted this would stay hidden much longer everyone being comfy with 
it.

Now it's creating pain: perfect, that makes the issue obvious, but it should 
be addressed not masked.

This is in part what Volker highlighted pointing out this should be less of a 
problem with key components being moved to Plasma. Again, if there are more, 
let's just address them.

So as pointed out by Sune and Volker: this is a feature (at least in the 
Frameworks case) not a bug.

> * This results in very frequent releases which creates a lot of work for
> distros and talking with some distro maintainers they seems to agree that
> having a big releases every 4 months is better than having constantly a new
> minor or major release from either Framework, Gear or Plasma.

This is a downstream relationship topic in this case.

I'm honestly unsure where the problem is though. They could decide to pick a 
set of version for the three and focus on that. They don't have and never had 
to package every single version of KDE Frameworks.

That being said it indicates to me that we're not good at communicating which 
KDE Frameworks version a given Plasma or Gear release targets. More 
coordination and communication here would make sense.

> * We currently don't have a stable branch for Framework and it takes often
> up to one month for fixes to be deployed. The Framework releases is also
> not in sync with either Gear nor Plasma while these two modules heavily
> make use of Framework and contribute to Framework.

This is a QA and testing topic in this case.

The intent is that master is the stable branch (as Luigi pointed out). If it's 
not stable in practice we're failing on testing on QA. So extra automated 
tests, more QA and so on should be provided. Yes this is work but it has a 
chance of increasing quality, changing the release cadence won't do anything 
about it.

> * We could have an unified LTS release including more than just Plasma. This
> is something that distros have been asking for some time already because
> having just Plasma receiving bug-fixes but not Framework nor the apps is
> not that helpful.

This is a downstream relationship topic in this case.

I'm not sure we need to go full steam on the LTS promise though. See above: 
better communication about the expected and QA'd versions of KDE Frameworks 
needed by Plasma for instance might be enough.

> * In term of promotion, it is very difficult to advertise the 3 releases
> because combined we have an important release of either Gear, Plasma or
> Framework every few weeks. This is too frequent and often while a combined
> announcement would have enough content to be published in a tech newspaper.
> When splitting the content accross 2 announcements (Gear and Plasma), we
> reduce the content per announcement and this makes it less interesting for
> the journalists to write about us. This doesn't come from me, this is that
> some journalists directly told me.

This is a marketing topic in this case.

I've never been really involved in the KDE marketing effort. Still, looking 
back at it years after I joined the community, and knowing what I know 
nowadays from seeing other projects and products, one thing which surprises me 
is that we're still on the mindset of hard coupling engineering releases and 
marketing announcements.

I think we passed the point where it was viable a long time ago.

I honestly wouldn't be shocked if there were engineering releases of KDE 
Frameworks and those would have just a changelog email, same thing for Plasma 
x.y.0 with no marketing announcement. And then have a single big marketing 
announcement for a Plasma x.y.2 per year with its own marketing name.

I'm not saying the paragraph above is exactly what we should do in terms of 
numbers, I'm just giving a rough example of how decoupling could look like. 
There are several different strategies to achieve this.

> * We won't have 3 different release teams but instead have a bigger one with
> a bigger bus factor. We could also unify the tooling for doing this mass
> releases a bit.

This is an engineering topic in this case (to be more accurate release 
engineering).

There are two aspects here: the number of people and the tooling. Getting more 
people would be good but if not, indeed that could be the same people pulling 
the trigger for rolling out the releases.

The tooling should indeed be unified as much as possible if that's not already 
the case. Executing a release should be the least work possible (if we don't 
consider the QA efforts, this is hard to compress).

> I do understand that there was valid reasons for splitting KDE Software
> Collection for Plasma 5 but I don't think this worked out. These were as
> far as I know the main arguments used for splitting the Software
> Collection.
> 
> * Trying to move away from "KDE" being recognized as the software instead of
> the community. This unfortunately didn't really work out, everyone is still
> using KDE to refer to the desktop. Even distros call their edition "KDE"
> and I don't blame them, it's difficult to find a better term than that as
> for example "Fedora KDE Spin" not only contains Plasma but also a lot of
> KDE apps. Splitting the releases won't help with that, we need to find a
> better approach or just let it go and accept that people will keep using
> KDE to describe the desktop/software.

This is incorrect in my humble opinion. My memory could fail me of course, but 
to me the splitting didn't happen "to move away from KDE being recognized as 
the software". This marketing move actually happened before. It just so happen 
that the splitting made it easier on the marketing side to identify the 
products.

The motive for splitting was mainly to a) be able to cater to different 
contributors and users needs and b) make structural problems more obvious.

> * Better promotion of our apps outside of Plasma. This is a valid point but
> I think pursuing our current strategy of putting our apps in many app store
> to be more effective. We could also show the platforms support of each
> applications more prominently in our releases announcements like we already
> do on apps.kde.org (e.g. https://apps.kde.org/okular/). Generally Plasma
> releases fare a lot better in term of promotion than the gear announcements
> and showing the applications on an unified announcement would likely help
> spread the words about our applications better.

Again, nothing to do with the split in my opinion. Like I mentioned before if 
marketing prefers to do a single announcement for Plasma + Gear when they see 
fit, this could totally happen today without a change on the engineering side.

> * Helps with outside usage of our frameworks. These didn't get as much
> success as we were hoping when splitting. I think having a stable branch
> for Framework might help but this is only a guess. It would be interesting
> to know of cases where people considered using some Framework and to know
> why they decided against or for it and if this proposal would helps or not.

Did KDE Frameworks take the Qt/C++ ecosystem by storm being used everywhere? 
No, indeed. We were not delusional though it wasn't the goal. We wanted to 
move from kdelibs is unusable outside of the KDE community to making it usable 
by third parties.

We can agree to disagree on the threshold at which this is considered a 
success. But to me it's definitely a success.

We moved to unused to some use both in other communities and in company 
projects we don't hear about on those lists (but they do exist). As Volker 
mentioned it's the dependencies and build system which are the limiting factor 
here (no wonder the most reused outside of KDE tend to be Tier 1 frameworks).


At this point, I think this highlights quite a bit the problems I have with 
this proposal. It is based on fragile premises conflating many different 
aspects. Also, instead of really addressing the issues, it's a proposal to 
move back to some "golden age of when we released everything in sync" which 
wouldn't solve all of the issues but only some of them (maybe)... and rub the 
rest under the carpet.

To me the most likely outcome is old and tough issues creeping back up. Give 
it enough time and entropy will run its course getting us back to the kdelibs 
big ball of mud and high coupling of all apps Plasma and otherwise to this 
kdelibs-ng. We spent years trying to get out of this particular mess, I'd 
appreciate if we don't jump back into it.

It'd also mean that the progress made on third parties using KDE Frameworks 
would completely go away. And in "fool me once, not twice" fashion we'd hardly 
get a chance of attracting them again.

> In effect this proposal would mean:
>
> * We do one major release every 4 months and then minor releases with a
> frequency based on the Fibonacci numbers as this releases cycle works very
> well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could
> unify that for one or the other one. Or let each component keep their
> current versioning scheme depending whether we want to merge Plama and Gear
> as product or keep it separate. I'm a bit undecided about this.

Indeed, the Fibonacci approach seems to work well for stabilizing minor 
releases of apps. Still, between minor releases the cadence should be 
constant.

I think Gear and Plasma should be separate products. Which doesn't exclude 
moving some apps from Gear to Plasma. To me this both strengthen Plasma and 
Gear if we're clear where things stand.

If an application is in Plasma it is expected to have a mandatory deep 
integration with Plasma sessions. If it's in Gear it is expected to be 
portable, maybe it does more under a Plasma session, but it shouldn't be 
crippled by running outside of a Plasma session.

Also, on the Plasma and Gear products I think it should be clearer which KDE 
Frameworks version is targeted.

> * "KDE Framework" will still exists as an entity and its ABI and API 
> compatibility requirement. Only change is the release frequency and the 
> introduction of a stable branch in sync with the other components.

I hope by now I made the case clear that the release cadence of this one is an 
intended feature and not a bug. In my opinion, any pain KDE Frameworks being 
on its own cadence creates somewhere else should be treated as a symptom of a 
structural problem and addressed for what it is (decoupling required, some 
component in the wrong product being an issue in the dependency chain, missing 
QA or automated tests to catch regressions, etc.).

Fun fact: "back then" we even toyed with the idea of an even faster cadence, 
it'd require quite some more automated QA and so was left on the side.
I still think it would be a possibility for a subset of frameworks for go on a 
faster cadence, but let's not open that can of worms.

> * Only have one release announcement on our website. We can call it
> Megarelease 6.XX like we did for Plasma 6/Gear 24.02 or find a better name.
> I would avoid reusing Software Collection first because the name is quite
> technical and second because these was already used in the past.

Sure, why not. This is not engineering I'm less opinionated about it. Apart 
from decoupling more between engineering effort and marketing announcements 
that is.

Maybe reconsider the "Megarelease" term though... I've literally been laughed 
at for the use of that term outside of our community. Also, I think it was a 
fine term for a one off when moving on a major new version of Qt, but it'll 
get old quickly for the "business as usual".

Again no strong opinion there, but I thought I'd mention what I've seen around 
me.

Regards.
--
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://hc.enioka.com/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20240419/dd291689/attachment-0001.sig>