 Can't Kitty just stop adding new features and focus on fixing bugs? Okay, I actually received that question quite a lot. So let's try to address it. Even via emails, you email me. Can't Kitty stop adding new features? Like I can't decide. I do contribute to Kitty though, so I should be able to answer this one. My personal opinion, personal opinion is that no, that's not actually feasible. It is a very naive idea. And let's actually try to understand why. So we do have something called the feature freezes. And that is roughly one month before releases, which means that you have released one month before you have a hard feature freeze, which means that no new big feature will get inside that you do from that day on will get inside the next release. If you do a big new feature, you cannot merge it to that release. And that is quite relevant because it actually gives us developers one month to make sure that everything works with quality assurance, this kind of things. And it also gives us the promotion group of Kitty, because I mean both the time to prepare the announcement and the video lately, Harron, a contributor for Proma has been doing a nice job in that. So this is extremely important. And it is very rightful to ask, okay, why can't we have that hard feature freeze where you cannot merge new big features for, I don't know, six months, four top a year? I don't know, every time I hear somebody, it's a different number. But okay, let's say that we do it, it's not going to work. And let me explain why. If right now, how it works is that if you do a very new big feature, during this hard freeze time, it will get merged, but not for the next release, but for the one after that. So we branch at the hard feature freeze, and we only merge the new features, new big features to the next release, the one in the future, whereas the closer release, we only do bug fixes. That's kind of how it works. So in order to have a hard feature freezes, that lasts for like four months, six months, you would require to have new merge request about features, and you would have to go to them and tell, no, this is not going to get landed until six months from now. Couldn't you just tell people not to make new merge request about big features? Yes, you could. Nobody would, nobody would listen to you, honestly, because listen, a lot of new features that we receive merge requests for are coming from people that are not very, you know, there are new commerce to the KD community, which is very nice. You come to the KD community, you propose something new, and you actually implement it. And those people will, we can't actually effectively tell those people to stop making new features. They are still going to come in, they won't, you know, really care about that, and they will do the thing for themselves, and then they will try to upstream it to KD community. There's also a lot of people with small distros that work on making KD Plasma better for their distro, and then upstream the change to KD Plasma itself. In order to have an art feature freeze, we would have to look at all of this merge request, which again, I can bet you would still be coming even if we publicly announced that we don't want them anymore. We would have to look at them and say, no, this is not going to happen until six months from now. Then there's core contributors. And again, I can bet you that even if we internally decide to have an art feature freeze for six months, core contributors will still do new features. The only thing that will change is that they won't propose them. They will keep on their local computers and just wait for the right moment to actually do them, because KD Plasma core developers are KD Plasma users. And whenever they see that they are missing some functionality that they do want, they are going to implement it if they have enough time. And keep in mind that most of currently KD does not hire any developer, which means that we are either doing this as a hobby or by being paid for other companies. And if we're doing this as a hobby, you can tell us what to do, you know. Yes, core KD developers are still going to make merge requests. The only thing that's going to change is that they will wait for the six months period of time to pass, which means that we would have like six months of not big new features, just bug fixes. And then after that, a ton of merge requests, all of the people that waited for that moment put all of the merge requests right there. And of course, you do also have to rebate some changes because six months is a long time. They could can change and you have to rebate your changes to the latest version. And that also takes more time. So you're making people lose time, in fact. And of course, as soon as that happens, like 100 of merge request, well, you're going to get a lot of new bugs because new features, new bugs, and okay, you've gone six months of bug fixes, just bug fixing. And then hundreds of merge requests will come anyway. So if you do a very long hard feature freeze, sooner or later, you have to finish that very long feature freeze. And when it finishes, you get all of the changes that people waited until that moment to submit, which makes the whole thing pointless. As always, this is my personal opinion on what would happen. This is my intuition. You can disagree. So is everything lost? Like is KD always going to implement a lot of new features that they don't have the time to actually bug fix? And I strongly disagree on this one. There is a way to tackle this issue. And I do think that there is currently an issue of too many bug reports. But the solution is not to just say, oh, they just have to focus on bug reports. And that that's it. It's much more complex. So firstly, we need more testing. And it's very easy to say, it's very complex to implement. And you might say, what do you mean? Doesn't KDE have tests on all of their code? Well, you know, some libraries does have like test, which makes sense. But most of KDE Plasma is UI. And it's not super easy to test UI. There are interesting projects. Like as an example, OpenSusa has this OpenQA tool, which basically runs some, um, runs some, you know, activities like pressing on buttons and such, and then takes a screenshot and then compares a screenshot to a reference one to make sure that everything aligns correctly. However, this is very hard to maintain in the long run. There has been attempts at bringing OpenQA to KDE, but those always failed. There are other ways. As an example, recently, there was a proposal to use accessibility accessibility tools to check for UI, you know, to do UI testing. That is also interesting. But to this moment, nothing like that is implemented, which doesn't mean that it will always stay like that. It means that we have to improve. And in fact, at the last KDE Academy, a new goal was selected, which was the automatize everything goal by Ned Graham. And one of the goals is to make sure that testing is better. Then there's also a lot of things to say about quality assurance. It's not just about testing. It's also about making sure that there is a team of QA people that test things manually to make sure that they work right before releases. And currently, there is no such team. Like there isn't, there is one, but nobody is in it. So it's not doing anything. Once we have a QI team, we can make sure that every merge request is approved by that QA team before actually merging it. And keep in mind that those things are all things that sounds very exciting that will actually improve KDE Plasma stability and reliability, regardless of how much KDE developers focus on backfixing on adding new features. Because whenever they want to add a new feature, there will be more testing, more QA and that new feature will be more stable when it actually reaches users. So this is extremely important. And really, this is the way to go. Finally, I want to end this with my impression is that KDE developers, myself included, know that there is more focus to be put regarding making sure that KDE Plasma is stable. And to be honest, if I take KDE Core developers, 95% to 100% of their time depending on the developer is spent on backfixing. Most of the stuff they do is backfixing. Whenever there is a new feature, usually it does not come from my KDE Core developer. The refactor, the backfix, they make sure that everything works nicely. So KDE developers are extremely focusing on backfixing and such. That is my impression. But of course, more people that come from outside and just joined the KDE community, they don't quite maybe have the skills yet to do larger factors. They don't quite understand the code base as a whole. So they add new stuff because it's very easy, it's very exciting to do, and it's easier. So usually you start off by adding new features and then you have the burden to backfix them. Again, this can be improved, I think, as a part of the automatized things, making sure that whenever there's someone new, maybe even young, that proposes new changes, new features, they also have all of the help from a QAT team to make sure that these new features are free from bugs and also that we can try to onboard people directly onto backfixing. But if you look at the last release of KDE Plasma, 5.26, that was extremely focused on backfixing. And if you look at the release before that, 5.25, that has some major new features that were very exciting. But we're all about making sure that KDE Plasma is usable for users. As an example, touchpad gestures. They're so incredibly necessary. You can just live without them. Or I don't know, the new overview screen is actually part of a rework of all KDE K-Win effects. So there has been a very large factor of effects and now they're much more simpler to maintain, which means less bugs. So again, we are incredibly focusing, from my point of view, on backfixing instead of adding new features. If we look at past Plasma releases, most of the stuff is backfixing, making stuff more stable and so on. However, I do want to say that there is always a need to add new features that make a product exciting. We cannot go maybe one release, maybe two, and that's really risky. We can't go a whole year without adding any kind of new release. Because I know that for KDE Plasma users, they think that we'll use KDE Plasma for their whole life. I don't think that's true. But you need to realize that in order to onboard other people to KDE Plasma, which is a goal we have, and in order to keep KDE Plasma users excited about KDE Plasma and wanting to use KDE Plasma, some new features you have to implement. You have to bring new things that users are asking for, such as touchpad gestures. And so often, I see people that say KDE Plasma should focus on backfixing without new features. And then they ask for features like they say KDE Plasma should be more stable. By the way, touchpad gestures are super important. KDE Plasma should have them. That's a gigantic new feature. There's a contradiction there. So new things are necessary. Just like final example, and then I'm out of here. Plasma 6 or whatever it will be called, there will be most of the focus on Plasma 6 will be on transitioning to Qt6 to frameworks 6 and making sure that everything works nicely, reliable and stable. This will be the main focus. There won't be any new shiny super big features. That will be the main focus because we know that's what KDE Plasma needs the most, I think. At the same time, it's Plasma 6. And if you go and announce Plasma 6 without any new features, any, well, that's a bummer from a promotional point of view. And we do need to keep in mind the promotional side of things as well. So KDE Plasma 6 should have some new features. Some maybe not like meant for KDE Plasma 6, but something that will excite people and make them use it. And then when they actually use it, they will see all of the focus that we have put into making it more stable, and then they will stay on it. To make an example, currently, there is a big rework from KD Core developers going on about multi-screen setups. We very much know that there's issues regarding multi-screen. We do see the bug reports. And there is indeed a rework on actually trying to address these kind of things. They're just not that easy to address, so it took time. So hopefully Plasma 5.27 or whatever is next, I don't remember exactly. We'll have this rework and will be more stable from this point of view. Me personally, I've done a lot of bug fixes. Just in the last week, I think I've done like five, six. That's a lot for me. So there is focus on bug fixing. But to say that we just should focus on bug fixing instead of adding new features, that's not going to work. That's not how it works.