KDE Plasma open-source developers were meeting the past week in Graz, Austria to plot out fundamental changes and improvements moving forward for this great desktop. Among the changes decided on were ending their practice of Plasma LTS releases, enhancing the telemetry capabilities to be more useful, and more.
Prominent KDE developer Nate Graham shared his notes today from the Graz sprint around some of the matters that were discussed. You can read all of his notes in full via this blog post while here are some of the most interesting tid-bits.
On the matter of Plasma Long Term Support (LTS) releases, those longer-maintained releases will be discontinued moving forward. Plasma LTS releases haven’t been too practical or widely used, so instead they’ll just be maintaining all Plasma releases slightly longer:
“Our conclusion was that the fairly limited nature of the product isn’t meeting anyone’s expectations, so we decided to not continue it. Instead, we’ll lengthen the effective support period of normal Plasma releases a bit by adding on an extra bug-fix release, taking us from five to six.”
Plasma developers also discussed moving from a 4-month cycle to a 6-month release cycle for Plasma to allow more time for bug-fixing and the like, plus Plasma 6 stabilizing rather nicely at this point. They decided to defer a decision for another four months after the next Plasma release and when the developers will be meeting at the annual Akademy conference.
Plasma developers also discussed the challenged around third-party content and theming, in particular with QML-bassed theming and the risks that it poses:
“The issue here is that QML-based theming is just inherently dangerous because QML is code; there’s not really a way to make QML theming safe, so we’re working on moving away from it.”
Plasma developers are also going to work on making the opt-in telemetry reporting more useful and akin to the Steam Hardware Survey:
“There was broad agreement that the status quo is not ideal: we collect very little data from people who have opted in (because it’s off by default), and we don’t have a path towards changing what data we collect in response to newly-discovered questions we’d like answered.
For example, let’s say we want to remove a very niche KWin effect that we think probably nobody’s using. Right now, we have no way of knowing how many people have it turned on, and of them, how many people are actually using it — let alone reaching out to ask them why! So we have to just go by gut feelings when we make that decision, or get spooked and not do it at all.
So we decided to change the way we collect telemetry to be more like the common and successful Steam Hardware Survey. Our telemetry UX will be the same: people will see a dialog window asking them to participate in the survey, and in there, they’ll see what data will be collected. They’ll have the opportunity to say yes, say no, or turn it off forever. And for each survey, we can tailor the data collected to what we actually want to know! So we could have it collect information about that KWin effect, and it could even prompt the people using it to write a little bit of text explaining why.”
Read more from the Graz sprint on Nate’s blog.
