Proposal unify back our release schedules

[Carl Schwan]

On Friday, April 19, 2024 6:39:01 PM GMT+2 Kevin Ottens wrote:
> 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.

Thanks you all for raising some important points. Taking into account the 
feedback, I would like to slightly change my proposal.

- Unify only the release schedule of Gear and Plasma with a frequency of 
either 4 months or 6 months. This would follow the Fibonacci release schedule.
- Keep framework release once every month. But ensure that once every 4 (or 6) 
months, it happens at the same time as Gear and Plasma. We can keep the 
frequent features release of framework, which seems to be valuable for people 
not compiling the whole stack from source.

For the occasion where the Framework, Gear and Plasma, we should then ensure 
that the framework release is done at the same time or slightly before the 
gear and plasma release and ideally there is also a special beta release of 
Framework done at the same time as the gear and  Plasma beta, which can be 
tested together with the other beta releases.

If Plasma decides to switch to a release every 6 months and Gear prefers to 
keep a shorter release cycle, then I would suggest using 3 months for gear so 
that we still have an unified released of framework, gear and plasma once every 
6 months. I'm less fan of this and if we have a very good reason to switch to 
a 6 months release cycle for Plasma, this argument should also apply to Gear.

> On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote:
> > 
> > * 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.

I'm been working a lot on the visual of applications across the whole stack 
and for me, the pain is mostly caused by the fact element of our styling are 
spread across the 3 releases: gear/plasma and framework. The megarelease has 
been tremendously helpful to get visual changes implemented consistently 
across the entire stack and I don't think this can be solved even with the 
best will.

Plasma holds Breeze which holds information about how our controls look like. 
There was discussion in the KF6 board to move breeze to be a framework but due 
to the license this is not possible (unless we change the definition of 
framework and allow GPL stuff).

Framework holds qqc2-desktop-style and breeze-icons as well as a lot of custom 
widgets frameworks like Kirigami, KWidgetsAddons, KConfigWidgets, KItemView, 
KXmlGui, ...

There are also a lot of libraries in gear which contains custom widgets (a lot 
in PIM but not only).

Apps themselves also contains a lot of design elements. This includes some 
custom widgets but also the general layout of the app and dialogs. This could 
be fixed by adding a lot more widgets in apps to KWidgetsAddons/Kirigami, but 
it doesn't always make sense as some widgets are super niche and don't belong 
to a Framework/library. Some examples from the recent redesign in the 
megarelease are the design of periodical table cell elements in Kalzium which 
previously followed the Oxygen guidelines and now is more Breeze looking. 
Another one is the layout of the Kate search and replace dock and a lot of 
other docks which had to be changed to have a more "frameless" look.

It won't solve the issue for extragear applications, but I don't want the 
search of a perfect solution for 100% of our apps prevent us to fix to improve 
the situation for at least a big chunk of them. Particularly since unifying 
the gear and plasma release, won't make the situation worse for the extragear 
application.

> > * 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.

Frameworks don't have stable releases, if distributions want bug fixes they 
currently have two choices:

- Update to the latest framework release continuously. This means they have to 
package every single version of KDE Frameworks and this is actually that we 
recommend officially for the better or worse (running a very recent framework 
release with a very old plasma is not well tested).
- Back-port every bug fixes in the packaging of the distro. This is duplicated 
work and I would argue that this is basically a stable branch but maintained 
out of tree, which is not ideal.

My solution was to do official stable release for Framework, but there seems to 
be some resistance to that idea.

> > * 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.

And even with perfect QA, we won't be able to cover all mistakes and we 
regularly end up with some regression in Framework. I think this is partially 
caused by less "apps/gear" developers testing their applications with 
Framework compiled from master. I think at least having a beta release at the 
same time as the gear and plasma release would be beneficial even if this means 
we don't do a framework beta release for every framework release.

> > * 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.

I'm a bit skeptical about the general LTS releases concept for KDE and I'm not 
advocating for doing them. Unless of course some downstream entity decides to 
spend engineering time on it and then as KDE we should facilitate this effort. 
My point is that if we want to do an LTS release, we need to not only have an 
LTS release of Plasma, but also Framework and Gear (or at least a part of 
gear). And having some sort of synchronization for the releases of these 
products would help a lot to archive that.

> > * 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 don't think it is remotely possible to decouple the engineering releases 
from the marketing announcements. As soon as the tarball are publicly 
available, 20 news articles appear in the internet before we even have the 
time to publish our announcement and I'm only slightly exaggerating. Many 
distributions will have the package available on their repositories in a 
matter of hours to days. We can't publish an announcement, two months later or 
it will be old news already.

And we do have engineering releases for framework which only contains the 
changelog: e.g. https://kde.org/announcements/frameworks/6/6.1.0/
We are just not promoting these because the format is way to dry for any end 
users and developers already usually get the news on their mailbox.

> 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).

Fortunately the tooling is slowly getting unified.

> > 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.

Okay, I wasn't around at that time and I just heard that this was one of the 
reason.

>> ....... 

> 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".

Yeah the megarelease term is not great. It was fine for a one time thing, but 
if we do unified releases of at least gear and plasma, we need to find an better 
name or do something else: e.g. use code names for releases like macOS do.

> 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