Why don't you just do bug fixes for 1 - 2 years?

Community
1

Hello!
I’ve been using KDE since about KDE 2 - at irregular intervals.
KDE 4 was exactly what I needed at the end and it worked very well for my purposes.
KDE 5 was unusable and KDE 6 is on a good way but still needs a lot of improvements.

Unfortunately, you have the habit of changing everything with every new version and reinventing the wheel.
Every time you have to set everything up again and get used to it again.

What is also annoying is that there are more and more bugs in KDE and programs that used to work are no longer usable. New ones are constantly being added, while old ones are not being fixed.
For example the bug 498490 ( 10.01.2025 ) which is a duplicate of 348047 ( 21.05.20215 ) is 10 years old and still not fixed.
There are still plenty of them and very few are marked as solved, which tells me that there is still a lot of work to be done.

It would be great if KDE was not a self-fulfillment of programmers, but a project that can also be used productively because it is user-oriented.

As we all know, hope dies last.

Think about it, it can only get better.
In any case, I wouldn’t recommend KDE to anyone in this state - especially not in a productive environment.

Yours sincerely, R.Lehmeier

2

Plasma 5 had some issues, but smoothed out again at 5.27.

Plasma 6 is much better by comparison with sweeping improvements.

Why would you sit polishing an old care for 20 years when you can create new and better cars?

However, if bug 498490 (10.01.2025) interests you so much, why don’t you change that?

Do you not think that there are some considerations?

  1. Is it an easy fix
  2. Is it a priority fix
  3. Is anyone available to work on it

It’s also more helpful (rather than making drunken rants) to post links instead of making meaningless statements; nobody knows or can be bothered searching for your little bug.

2 Likes
3

That’s far too late, because what good is it if everything is fine in the end but by then it’s just trouble, only to be replaced shortly afterwards by the next faulty system. There may be problems at the beginning, but then it must not be released as productive and replace a functioning system.
This way of working is not acceptable.

I hope so, because it could hardly get any worse and waiting for it to be used productively years later cannot be a solution either.

True, but why should I install faulty software if it still works and why isn’t it gradually replaced so that you can keep your settings and working methods?
You can tinker with the system for as long as you like, the main thing is that you can use it all the time without noticing the changes - unless they are to your advantage (for example, making it faster).

If I could, I would do it and provide the patch.
But I can’t, because I’m just a user and not a developer.

It’s not just about my bug, that was just an example.

It’s mainly about the fact that you don’t fix a lot of bugs and (let’s call it a sabbatical year from the new one) that you need to work through the bugs and then stand on a much better basis again and bring out a better product.
A product that is so good that everyone would like to work with it and not turn away because you scare your users away in droves because you have to redo everything with every new version.
This is not just about a small bug but about your way of working as a whole.

I am the last person who can / wants to tell you how to work. But I take the right to point out to you that you should not go on like this because it leads you to a dead end - and KDE does not deserve that.

Because it used to be the best desktop and should be again.

4

I didn’t have any problem, I held back and waited for it to stabilise - I’m not interested to run the latest unstable version.

All software is ‘faulty’ - it’s a matter of degree, and not everyone has the same experience.

I haven’t had to redo everything with every new version, though Plasma 6 did need a lot of clearing out before the update.

Many of the ‘bugs’ in Plasma don’t bother me at all - yet some of the ‘bugs’ seem to be accepted by many people, so my wish to ‘fix’ them is often overlooked.

5

For me ( EndeavourOs ) KDE is installed with the normal updates. I can’t hold anything back.
So I find it very strange that such unfinished software is being distributed.
Then KDE should make 2 branches. Stable and unstable or testing. Only when the new version is ready should it be released for the normal user. Until then there will be the bugfixed version without major new features.

It is true that there is no such thing as error-free software and I am pleased for you that you do not seem to have any significant errors or can ignore them. However, I would like what is offered to work properly. Unfortunately it doesn’t, hence the bugs.

For me ( EndeavourOS ) KDE is delivered with the updates and I expect it to work then.
Any cleanup work should be done by KDE as I want to work with it and not be bothered by it. The developers know best what changes and what can be removed.
I just want to work with it and do so as simply and efficiently as possible.

I am pleased that you are not bothered by bugs and that others probably don’t care about them either.
They annoy me as soon as they appear and are then reported. In the hope that they will be fixed.
Because a known bug should always be fixed so that the system as a whole is easier to handle and runs better.
If I have a project like KDE that is to be used by as many people as possible, then stability and working as easily as possible should be made possible and my personal wishes as a programmer should take second place - especially when I see that others have big problems with it.
Therefore I am still of the opinion that the known bugs should be fixed first before a new version is released.
Preferably at the end of the version, as this is the basis for the next version and is therefore more stable and better.

But unfortunately I have to reckon with the fact that a user’s opinion counts for nothing here.

6

It seems like both the post and the answer are missing one key point, which has been repeated thousands of times across hundreds of forums about software developed by communities: developers are volunteers. They work on things with the same motives as users, actually much better because they take their time solving things they don’t suffer from.
If the problem is how the work is organized, the best thing to do is not to rant, but to ask how to get involved to take some of the burden of the project, in order to free (or add) resources to the project so that more paid developers can be taken and so that the current volunteers do not have to spend time on trivial stuff. This means getting involved: Get Involved - KDE Community Wiki

Regarding the bug fixing, it happens a lot: it is just a complex matter, often due to the fact the KDE misses people triaging bugs (something which a non-developer could sometimes do, therefore — again — get involved). The blogs of KDE (and personal blogs of various developers, which I can link if you want) often report about bug fixes: https://blogs.kde.org/
One of the most important blogs has been tracking bug fixes for a long time: This Week in Plasma - KDE Blogs

One way to get involved is to participate in discussions about KDE works and needs, in places you can reach through the first link I added, or even posting a well-thought opinion with proposal on how to move forward, but you just posted a rant.

9 Likes
7

This is exactly how it is done.

A main branch, on which normal development happens, and release branches which only get bug fixes applied.

Sometimes there are additional work or feature branches when people work on things that need more time before they can become part of the main branch.

Lets have a look at Plasma Desktop as an example: we can see the main branch (master), several release branches (Plasma/6.3, Plasma/6.2, Plasma/5.27, etc), and several work branches.

Each release is governed by a series of steps.
There is usually a “freeze” (no new features, no new translatable strings, etc) at some point before a release, which then leads to the creation of the release branch.

After that the main branch becomes open for development of the next future release while the release branch receives bug fixes and respective “patch level” releases.

Again with Plasma as the example: freeze happened end of August 2024, with the release branch being created after about two weeks,
Then, after beta testing phase of about one month, the actual release happened, followed by bug fix released every couple of weeks.

Special branches like Plasma 5.27 which got shipped by LTS distributions receive such updates for a long time.

4 Likes
8

I’ll answer the question literally first, then offer some context.

Answer to question

There are multiple reasons why KDE’s developers don’t focus on just bug-fixing for two years:

You don’t say no to getting paid: A great deal of development in KDE is in fact sponsored by someone, and they often sponsor features. Saying no would mean less sponsored development in general, rather than a substitution of bugfixes for features.

It’s not realistic: The line between a bug fix and a feature can be blurry. Is implementing a useful Wayland protocol a feature or a bug fix? How about porting software to use newer libraries, backends, or drivers? What about improving the UI for something that’s currently awkward? These kinds of work are important long-term and cannot be neglected.

You wouldn’t actually want it: Even if focusing only on bug-fixing for two years were possible, it would make us fall behind the competition. KDE does not exist in a vacuum, and our software is always being compared to other options. Here is the full list of what KDE software wouldn’t have if we hadn’t implemented any new features over the past two years, just going by the naive definition of “feature” as "tracked by a Bugzilla ticket with the “wishlist” severity.

Context

Zooming out, I can understand that you’re frustrated that certain things you find to be important aren’t improving or being fixed as fast as you would prefer. That’s understandable. I get annoyed too when I encounter bugs.

But it’s important to zoom out even more and remember that KDE didn’t charge any money for any of this stuff; it truly is provided “as-is”. The whole thing is a gift we give away to the world for free. The facts that developers are willing to improve it for free in their spare time and then give away the results, and that companies are willing to put hundreds of thousands or millions of dollars into it and also accept that the results will be given away for free — are nothing short of modern miracles.

Now, does this mean we should be complacent and not care about improving it further? Of course not! But it does help to re-align expectations. I find that it helps to approach problems with a “how can I help?” attitude rather than a “why didn’t someone already fix this?” attitude.

A good way to start helping is to provide a clear description of what problems you’re facing. You already mentioned one bug report. That’s good! What about the others? Reporting bugs using bugzilla.kde.org is the first step, and being clear about which ones are important to you in communications here is the next one.

Beyond that, additional options include:

There are more too, these are just a few examples. But you are not a number, a faceless user with no agency, or an annoyance to be ignored! In a project as small personnel-wise as KDE is relative to its impact, every person matters.

12 Likes
9

That reads quite well. But how is it that the versions before 5.27, for example, were also delivered, even though they were not stable?

That’s the annoying thing, not only that you had to put up with everything up to 5.27, but that there is/was apparently no way to get KDE until it is stable. In this case from 5.27 and when KDE 6 is really stable that the version is only rolled out then.
Who is responsible for this? Then you could perhaps ask them why you also get the versions that are not stable enough.

Otherwise I think KDE is good, but it’s just annoying when you have to start all over again with every version.

10

I think we are not agreeing on what’s stable, as other releases have been tested until they were “stable”. But if for you those were not stable, it means that you refer to some issues which made them not usable. Are these issues in fact so critical? Did you report them, or did you open discussions about them?

1 Like
11

This is probably a misunderstanding.

Each release in the Plasma 5 series followed the mentioned process, so there were 27 stable releases before 5.27.

I’ve only used 5.27 as an example of a branch which shows how even previous releases will continue to receive fixes.
Sometimes for years due to being the version shipped by a slower moving distribution like Debian or RHEL.

there is/was apparently no way to get KDE until it is stable.

It is also possible to get KDE software before a stable release.
Usually that means enabling some “Testing” package source of your distribution or installing a “Testing” version of that distribution.

See for example the latest Plasma beta announcement.

There are even options to so-called “nightly builds”, for example KDE Neon’s “Unstable Edition”.
These contain software built once a day based on the state of the main development branch.

Ultimately it is possible to build any branch in any state locally.
Either by manually cloning the code and build it or using tools such as kde-builder

12

What you want can be achieved by changing distro . Debian Stable updates after every 2 years and in those 2 years you get only security updates , So you would be with stable plasma-5.27 that you wanted and would get plasma 6 in August 2025

Rolling-release distros will always have the pro of having latest software with the con of those software not being tested upon as long as LTS versions of those software in LTS distros like that of Debian and Ubuntu

3 Likes
13

Agreed - this is one reason there are a number of Plasma users who tend to prefer Manjaro to Arch or EOs… not exactly for being a ‘stable’ (read ‘Archaic’ release) but simply being held back when releases start causing issues.

Meanwhile, devs are working hard - and mostly unpaid - so the most we can do is politely suggest from our position of ignorance.

There are LTS releases to fall back on when the regular releases disappoint.

Anyway, upgrading to Plasma 6 requires that you follow some detailed guides - including .cache cleanups and resetting much of the config options.

14

For me, stable means :

  1. that it runs stable and
  2. that it can do what the previous version could do.
  3. that you don’t have to make changes again because something has been changed compared to the previous version so that it no longer works as before.
15

Unfortunately this is the definition of “coherent” instead of “stable”. If what you are experiencing are sudden changes to the workflow introduced by updates, the problem is not bug fixing but poor development planning. This is in fact the primary point of your post, but it hasn’t been addressed because the post then steered heavily on the bug fixing part and the title is actually about bug fixing.
You can start another discussion about the efforts made to ensure coherence of workflow across releases, then maybe someone will able to answer on that regard.

There’s also the problem of regressions, for sure, but that’s again a problem of having people spend their time and of people not reporting such issues during testing phase.

16

Since we seem to have a different view of stability, I would like to give you an example.

I will use Libereoffice for this, with the old numbering.
For example, when 7.0.0 was released, it was not recommended to use it for productive purposes. If you stuck to this scheme, you always had the most stable version that could do everything and was reliable.
In addition, 7.1.0 was also released from 7.0.3 onwards. By the time 7.1.3 was released, 7.0.6 was the last version of the 7.0 line. 7.1.4 was then the first stable version for the 7.1 line.
Nothing ever had to be reset. New versions were never pushed through. The old settings were retained and the new ones were available when required. That’s how it should be and not that you have to start adjusting everything again with a new version. This is just as unacceptable in a business environment as it is in a private one - or should I explain to my grandmother every time how she can adjust everything?

The fact that you can recompile each branch is great, but unfortunately of no interest to a pure user, who is only interested in whether it works and whether he has to put in an unnecessary amount of work.
If he has to put in an unnecessary amount of work, then he has no interest in the project / product - and leaves.
So you have to ask yourself who you are working for.
Are you just working for your own pleasure or do you want to provide the best desktop that everyone wants to use all the time?

17

I used to have Debian stable. It was very stable but unfortunately the software was also totally outdated (at that time 3 - 4 years) and this applied not only to the desktop but to all the software.

So, after some detours, I ended up with EndeavorOs.
I would suggest to EndeavourOs if there could be 2 lines, but for that these 2 lines must also exist.
Do these 2 lines exist? And I don’t mean the pure developer version but the stable version. In the function in something like I had already written krake. So that the friction losses on the part of the user are kept as low as possible.

18

I was already traveling with Manjaro, a good system that has always moved further away from the original Arch and is subordinate to a company. These were also the reasons why I switched to EndeavorOs.

I would never try to dictate to a developer, who is mostly unpaid, hard work, but I don’t think it’s more than right to give my opinion on a topic if I think this great project is going in the wrong direction - and ignoring the users is such a wrong direction.

When I read that when updating from KDE 5 to KDE 6, I have to follow instructions that ask me to clear the cache (many users don’t even know they have one) and reset most of the configuration options. It is precisely these configurations that make up a large part of the work to adapt the desktop to the working needs of the user.

When such an upgrade is carried out, the system should, for example, delete the cache (with a warning, of course, so that it can be canceled or confirmed) and take over the configurations of the old system, so that a smooth transition is possible without any additional work by the user.

Only in this way will you, in the long run, win the hearts of the users.

19

Unfortunately these are in conflict, and it’s very difficult to get both simultaneously.

If you don’t want the software to be totally outdated, then you have to accept that sometimes the developers will change the UX over time. Any project that doesn’t make these changes will eventually stagnate and die, outcompeted by newer and more nimble offerings.

The move from Plasma 5 to Plasma 6 was a “major version bump” where, yes, we made more UX changes than usual, and intentionally broke compatibility with 3rd-party widgets in order to improve the widget system in general. We didn’t do this lightly; we felt it was necessary to ensure maintanability and keep Plasma relevant. Plasma 5 users got 10 years of relative stability with a core UX that didn’t change much, and it’s my hope that Plasma 6 users will get the same thing.

Needing to clear the cache or delete settings smell like bugs to me; I’m not familiar with that you’re talking about specifically. These were not things that users were intended to have to know or do.

20

Ok, if it is the case that I have expressed myself incorrectly then I am sorry and I would like to apologize for that.

My point was always that the development was not meeting the needs, because as a user you had to redo everything every time a new version was released.

I can’t imagine that a developer would be happy to realize that the users are more dissatisfied with the new version than with the old one.
It should also be in the developers’ interest that their customers (users) can easily familiarize themselves with the system and notice as little as possible of what is underneath the GUI.
If I don’t notice a change and have all the options when needed, then the developer has done a good job and can rightly be proud of it.

1 Like