'KDE Plasma LTS Releases Are Dead' (itsfoss.com) 14
With its Start menu-style application launcher and its bottom-of-the-screen taskbar, KDE Plasma is a "nice" and "traditional" desktop environment that's "also highly customizable," notes It's FOSS News.
But there's a change coming... In contrast to other desktop environments, KDE offers a long-term support release (LTS) of Plasma, where bug fixes and security updates are provided for an extended period, with no new major changes being introduced. However, that is no longer the case now. Shared by Nate Graham, a prominent contributor within the KDE community, KDE has decided to stop working on LTS releases of Plasma, shifting its focus on extending support for the bug-fix and feature releases instead.
The reasoning behind this move is multi-faceted, with factors such as inconsistent expectations from the community, developers' reluctance to work on older versions, and the lack of consistency in LTS support for Frameworks and Gear apps... I believe this move will provide Plasma users with a better Linux desktop experience, thanks to the extended bug-fix period, which will enhance the stability of each release.
From Graham's blog post: It's no secret that our Plasma LTS ("Long-Term Support") product isn't great. It really only means we backport bug-fixes for longer than usual — usually without even testing them, since no Plasma developers enjoy living on or testing old branches. And there's no corresponding LTS product for Frameworks or Gear apps, leaving a lot of holes in the LTS umbrella. Then there's the fact that "LTS" means different things to different people; many have an expansive definition of the term that gives them expectations of stability that are impossible to meet.
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.
We also revisited the topic of reducing from three to two Plasma feature releases per year, with a much longer bug-fix release schedule. It would effectively make every Plasma version a sort of mini-LTS, and we'd also try to align them with the twice-yearly release schedules of Kubuntu and Fedora.
However, the concept of "Long-Term Support" doesn't go away just because we're not giving that label to any of our software releases anymore. Really, it was always a label applied by distros anyway — the distros doing the hard work of building an LTS final product out of myriad software components that were never themselves declared LTS by their own developers. It's a lot of work.
So we decided to strengthen our messaging that users of KDE software on LTS distros should be reporting issues to their distro, and not to KDE. An LTS software stack is complex and requires a lot of engineering effort to stabilize; the most appropriate people to triage issues on LTS distros are the engineers putting them together. This will free up time among KDE's bug triagers and developers to focus on current issues they can reproduce and fix, rather than wasting time on issues that can't be reproduced due to a hugely different software stack, or that were fixed months or years ago yet reported to us anyway due to many users' unfamiliarity with software release schedules and bug reporting.
But there's a change coming... In contrast to other desktop environments, KDE offers a long-term support release (LTS) of Plasma, where bug fixes and security updates are provided for an extended period, with no new major changes being introduced. However, that is no longer the case now. Shared by Nate Graham, a prominent contributor within the KDE community, KDE has decided to stop working on LTS releases of Plasma, shifting its focus on extending support for the bug-fix and feature releases instead.
The reasoning behind this move is multi-faceted, with factors such as inconsistent expectations from the community, developers' reluctance to work on older versions, and the lack of consistency in LTS support for Frameworks and Gear apps... I believe this move will provide Plasma users with a better Linux desktop experience, thanks to the extended bug-fix period, which will enhance the stability of each release.
From Graham's blog post: It's no secret that our Plasma LTS ("Long-Term Support") product isn't great. It really only means we backport bug-fixes for longer than usual — usually without even testing them, since no Plasma developers enjoy living on or testing old branches. And there's no corresponding LTS product for Frameworks or Gear apps, leaving a lot of holes in the LTS umbrella. Then there's the fact that "LTS" means different things to different people; many have an expansive definition of the term that gives them expectations of stability that are impossible to meet.
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.
We also revisited the topic of reducing from three to two Plasma feature releases per year, with a much longer bug-fix release schedule. It would effectively make every Plasma version a sort of mini-LTS, and we'd also try to align them with the twice-yearly release schedules of Kubuntu and Fedora.
However, the concept of "Long-Term Support" doesn't go away just because we're not giving that label to any of our software releases anymore. Really, it was always a label applied by distros anyway — the distros doing the hard work of building an LTS final product out of myriad software components that were never themselves declared LTS by their own developers. It's a lot of work.
So we decided to strengthen our messaging that users of KDE software on LTS distros should be reporting issues to their distro, and not to KDE. An LTS software stack is complex and requires a lot of engineering effort to stabilize; the most appropriate people to triage issues on LTS distros are the engineers putting them together. This will free up time among KDE's bug triagers and developers to focus on current issues they can reproduce and fix, rather than wasting time on issues that can't be reproduced due to a hugely different software stack, or that were fixed months or years ago yet reported to us anyway due to many users' unfamiliarity with software release schedules and bug reporting.
LTS's are obsolete (Score:2)
Re:LTS's are obsolete (Score:4, Insightful)
Spoken like someone who has never worked in corporate IT.
Sometimes stability is important, and having developers "move fast and break things" is the last thing you want.
Re: (Score:2)
Spoken like someone who has never worked in corporate IT.
Agreed!
Also spoken as someone who is young and hasn't had to waste a significant period of his life on needless upgrades, or who lives on his computer (or in his mother's basement or both).
I use LTS because I want my software to work and to work for longer than the day I install it. I sue LTS because I have better things to do than chase down upgrades or live on the bleeding edge of essentially a rolling GIT release of my whole system because some developer decides that my desktop can't live without a libr
Re: (Score:3)
I use LTS because I want my software to work and to work for longer than the day I install it.
That's perfectly reasonable. Now what's your plan to have this funded? Best I can suggest is for everyone in this room to buy suse.com support subscriptions, then they might have extra money to support another KDE maintainer.
Due to.. (Score:2)
Re: (Score:2)
Kubuntu and Neon (Score:2)
Depending on what 'extended support' is going to mean I might look a Neon with it's rolling release schedule.
This is the challenge of FOSS (Score:3)
This is, unfortunately, the largest challenge of FOSS. Developers who work on it for the love of it are often disconnected from normal users, and, well let's call a spade a spade, from reality in general.
Developers on FOSS often write because it's something they want to use. Which is ok, but a developer/power user has very different needs, wants, and skill level from the general class of users. You want to know why the "Year of the Linux Desktop" is so cliche a joke, that's why. That's why right there. Users don't enjoy living on the bleeding edge. They want and need it to just work, and to work for a longer period of time than the day they install it.
No one wants to have to operate a bleeding edge development rig to RUN this shit.
Jesus... are you actively trying to get distros to drop your product? This is how to do it:
- Step one, blame the user for not wanting a rolling-release home-built Linux From Scratch via Git rig.
- Step two, pawn off the responsibility for maintaining YOUR software to the distributions. Because the volunteers at Debian who package this want to have to know your software better than your own developers and have so much extra time.
- Step three, watch the distros you are giving the finger to run and your adoption tank.
KDE already has a far lower uptake, and is declining. There's a reason that Mint never released a KDE version. Maybe this is just KDE's way of ceding the user-space market they are losing anyway, and to focus only on the bleeding-edge crowd. I just feel bad for normal users who get sucked into KDE not knowing it's a mine field.
Re: (Score:2)
Correction, Mint had KDE and dropped it with Mint 19. Which, actually, makes my point.
Re: (Score:2)
You have good points but you also go into caricature. Nobody expects KDE users to run from git. KDE releases monthly bugfixes an a new Plasma version every 4 months. I don't know why you would call KDE a minefield. It works great.
Re: (Score:3)
"Importance" vs "Interesting" (Score:2)
One of the real issues in open-source software (referenced above) is the fact that you can't really force unpaid volunteers towards tasks that are uninteresting, such as maintaining years-old software that might not be heavily used. Maintaining LTS releases is definitely important but not necessarily interesting. And finding that balance to keep volunteers helping can be very tricky.
Even Microsoft struggles with this: Part of the reason they made Windows 10 free were the costs associated with having to