The 15-Minute Bug Initiative

Planning 2 Minutes

In my 2022 roadmap, I mentioned something called the “15-Minute Bug Initiative.” Today I’d like to flesh it out and request participation! This blog post is not only informational, but I really hope any developers reading along will get excited and decide to participate. 🙂

KDE software has historically been accused of being resource-intensive, ugly, and buggy. Over the years we’ve largely resolved the first two, but the issue of bugginess persists.

Have you ever had that experience where you’re introducing someone to a KDE Plasma system and to your horror, they run into multiple bugs within moments? These are the issues we need to fix first: those that can be easily encountered within 15 minutes of basic usage. They leave a bad taste in people’s mouths and provide the impression that the system is a house of cards. It’s time to remedy this final strategic weakness of KDE, starting with Plasma itself. So I’d like to present our initial list of bugs:

https://tinyurl.com/plasma-15-minute-bugs

If you have any software development skills, working on these bugs is a super impactful way to make a difference with code!! Every fixed bug is a huge deal, and brings Plasma meaningfully closer to a position of true stability.

Likely-to-be-frequently-asked questions

1. What are the criteria for being a 15-minute bug?

It’s an inherently squishy thing, but I look for the following:

  1. Affects the default setup
  2. 100% reproducible
  3. Something basic doesn’t work (e.g. a button doesn’t do anything when clicked)
  4. Something basic looks visually broken
  5. Causes Plasma or the full session to crash
  6. Requires a reboot or terminal commands to fix
  7. The bug report has more than 5 duplicates

The more of those conditions apply, the more likely that any Plasma user will run into it quickly during normal usage, and the more I feel like it qualifies.

2. Who determines what gets to be a 15-minute bug?

KDE developers and bug triagers make the call.

3. I’m a developer or bug triager; how do I add a bug to this list?

Change its Priority to HI. If you don’t have permission to do this, ask sysadmins for “editbugs” permission over here: https://phabricator.kde.org/maniphest/task/edit/form/2/

4. I’m not a developer or a bug triager; how can I help?

You can go through the list and try to reproduce or confim the bugs, and do investigation into root causes and triggering factors for the ones where this isn’t already known. Those are important because a skilled developer can usually quickly fix a bug they can reproduce. But if they can’t, then they may never be able to. So if you can help developers reproduce bugs, that’s extremely valuable.

5. I’m experiencing this annoying issue that’s not on the list! Can you add it?

Maybe. Mention the 15-minute bug initiative in the bug report for it, and KDE’s bug triagers will see if it makes the cut.

6. Why are you only doing Plasma bugs right now?

Lack of resources. The list currently has almost 100 bugs, and I don’t anticipate that we’ll get it down to zero in a year. A lot of the issues there are quite challenging to fix. But if I’m wrong and we blaze through everything, then I’ll absolutely broaden the initiative to include first frameworks, and then apps! Stabilize all the things!

So that’s the 15-Minute Bug Initiative. Let’s get cracking and make Plasma rock solid in 2022!

https://tinyurl.com/plasma-15-minute-bugs

Published by Nate

Published

37 thoughts on “The 15-Minute Bug Initiative”

  1. OK KDE 5.x (is it 24 or 25?) is the KDE version that refuses to DIE. Nobody there seems to want to call a FEATURE FREEZE. You adding new stuff which breaks OLD stuff that was working fine; you still refuse to simply adding virtual desktops with each VD having its own Wallpaper and its own set set of Widgets, something that worked fine in KDE 4.14; now you can only get the same effect via “Activities” only by jumping through a number of hoops, none of which are intuitive, and a feature a large number of people have been asking you to add, but NO, you can’t do that. Instead you keep screwing with KDE Plasma Wayland, but you also are keeping KDE Plasma X11. Wayland freezes my screen; I end up in a login loop in X11, which forces me to login as Wayland, and then back into X11 to finally login. the solution was to nuke SDDM and install LightDM, and use the X11 version ONLY.

    Here is how to FIX most of your problems. Follow the K.I.S.S. rules — Keep It Simple Stupid: KDE in its current state is far too complex to use to be useful. You keep adding stuff that nobody wants to use right now, though might have potential way down the road. Wayland is still EXPERIMENTAL — FORK IT!! Concentrate on JUST the X11 stuff and get all the parts working like a fine Swiss Watch. 2. Give the USERS back their Virtual Desktops rather than force feeding them “Activities” to accomplish the very same thing they were able to do way back in KDE 4.06 and perfected in 4.14. 3.If you are going to to introduce a NEW FEATURE, Then SHOW users how to USE IT!!! What does that mean? It means that you get people who can create YouTube Videos to create a SINGLE VIDEO that covers that SINGLE FEATURE in a STEP-BY-STEP video, as well as to WRITE a MANUAL on how to use it.

    Stop blaming USERS who feel KDE 5 is the most chaotic pile of steaming crap there ever was — there is ZERO FOCUS behind it. Instead of having a fine Swiss Watch, you end up with a pile of gears that you’re lucky to get to work unless you are am amateur watch builder. In its current form, a truck load of Industrial Strength RAID will not kill all the bugs in KDE.

    I FINALLY got KDE to work the way *I* work, bnut no thanks to the jokers over there at KDE

    Like

    Reply

    1. Sorry you feel this way, if I remember correctly adding widgets per virtual desktop would be hard to do in the current state and the majority of people wouldn’t use it.

      I do agree with you that fixing bugs is important, in fact, this post was entirely about that, not about adding new features.

      Liked by 1 person

    2. Widget per virtual desktop.
      The solution to this is to use workspaces.
      You can use wallpapers per workspace too. (would be nice to have that for desktops though ^^)

      The only issue, the lag it has changing workspaces.
      It’s not as smooth as changing virtual desktops.
      If it was, I’d probably use it.

      As a side note, was that fixed ?, changing the virtual desktop with a mouse wheel scroll ?
      Err, doesn’t look like it… 😦
      https://bugs.kde.org/show_bug.cgi?id=419867

      Scroll to switch desktop stopped working from kde

      I don’t know exactly what info you guys need, just lemme know..
      I’ll upload whatever it is you need for debug logs.

      Oh as a side note, before I forget.
      The taskmgr (either ver, activity mon or the old ksysguard / better ver lol).
      Right click on a task, detailed mem info.
      Crash.
      Oh, whoops, I can fix this on my end myself…
      “Running as root without –no-sandbox is not supported”

      Like

    3. -Not reading what the post is about
      -Attacking and complaining like he paid for the product
      -Ditacte how the project should go without the smallest idea of what the devs had planned for the future

      Classic linux user in action

      Liked by 2 people

    4. I disagree about focusing at X11. They should probably halt/cancel any X11 improvements and put all efforts into Wayland due to;
      * Very limited available resources to perform the updates (cannot maintain 2 display servers simultaneously)
      * Wayland is the future

      In comparison, SpaceX halted all improvements for Falcon 9 (their old rocket) when Starship development began (their new rocket), in order to focus all resources into Starship. Any resource to Falcon 9 would have been a wasted resource for Starship. Sure the Falcon 9 could have had huge improvements (like reusable second stage), but the whole system is obsolete when Starship becomes active. It is better to get the new one active faster.

      KDE team needs to think the same way.

      Like

    5. Wayland is unusable for people on pre-800 NVidia GPUs, unless they switch to Nouveau. Abandoning X11 immediately will make the experience worse for those people.

      Like

    7. I disagree…
      I use x11 and will do so until wayland is stable enough.
      And tbh, I may end up sticking with it anyways who knows.

      The frametime lag is bad though.
      Either with compositing on, or using ogl as the renderer vs software.
      If you go the latter route, it’s a bit glitchy.
      But tbh, I can use some of that to debug the desktop qml a little more.

      I think anyways, didn’t triple check… (later notes kinda confound me)

      # raster has glitches on the desktop and taskbar thing in kde5
      # but the frametime issues are gone with it
      # export QT_GRAPHICSSYSTEM=”native”
      # export QT_GRAPHICSSYSTEM=”raster”
      # export QT_GRAPHICSSYSTEM=”opengl”

      # update, it’s this not raster that causes the glitches, in software mode
      echo “SceneGraphBackend=opengl” >> “/root/.config/kdeglobals”
      # echo “SceneGraphBackend=software” >> “/root/.config/kdeglobals”

      As a side note, x11, 30bit finalizing would be nice.
      Chrome works now.
      It really just needs a few transparencies fixed and that’s it. (half works, half doesn’t)
      If I could force each app to render in 24bit mode instead with an env var that would be good enough.
      As an alt workaround.

      Like

    8. If you feel that way just use GNOME instead. They tried the KISS approach and some of us don’t like the result at all. Hence we now use KDE for what it is and we like it just for that. It would be stupid if KDE would go down the path you propose. On some wild goose chase to turn KDE into something that it is not

      Liked by 2 people

    9. Very disrespectful, rude, and hateful comment, showing great ignorance and anger management issues. Please temper your inner Karen before spending 10+ minutes writing such comments, full of shouting (all caps), demanding and wailing like a little child that got a yellow lollipop instead of a blue one, thinking you are smart and everyone else is an idiot…
      Well KDE is fully open-source, so you can go ahead and fork it if you want to… Or go use something else
      KDE is developed by volunteers, in their free time, not by a multi-billion-dollar company employing full-time developers. Instead of yelling at them in the comment section of a blog post, get involved. Send bug reports (not like “You are stupid, fix this right fkn now, how can you be such clowns in 2022 to have this issue”, but with meaningful information, and a desire to actually help the project), fix bugs yourself and send merge requests (again, be nice), translate some strings to a non-English language you know, etc. instead of flinging poop at the developers.
      KDE 6 is coming, but there is not supposed to be a feature freeze ever. It happens before every Plasma and Frameworks release. Then the Beta is released (like the Plasma 5.24 Beta is out now), and many bugs are fixed, then it is released, and development starts on the next release. KDE 6 will just be a (hopefully) smooth transition to Qt 6, the next version of the underlying toolkit. Not as big a jump as KDE 4 to KDE 5 was.
      Activities are not shoved down your throat. You can always just not use them. Yes, KDE has 2 different concept of “workspaces”, first you have Virtual Desktops (which only serve to separate windows into groups inside an Activity), and you have Activities (which are the classical Workspace concept, intended to switch between different things you do with your computer: one for gaming, one for development, one for lewd stuff, etc; with different tools and configurations (including the wallpaper) that fit the particular use-case). The concept you have always been looking for is Activities, and they were streamlined in Plasma 5, and are much more flexible than the Virtual Desktops implementation. Virtual Desktops only exist to separate windows inside Activities, and to not break the muscle memory of folks who got used to archaic KDE software with its rigid Workspace system.
      For the Wayland and SDDM issues, report it and look into the root cause, instead of complaining in anger.
      Why don’t YOU crate those youtube videos since you seem to know everything?
      No one blamed the users. Actually, this blog post is about fixing the most glaring bugs in KDE, from a development POV. No one mentioned the user being at fault. If you read this blog regularly, you would know that Nate wants to understand the users: how they interact with computers, what they need, stc, and cater for them. Not just one user (i.e. you), but all of them. So KDE devs are working on what they think most users need, and what they know how to do, not what one individual tells them.

      Liked by 2 people

    1. Yeah, this would be a glorious idea. I’ve had nothing but data-threatening bugs with activities. It always felt so fragile to use. So I only have one now and I’m happy, I wish I could just scrap that feature altogether.

      Like

    2. Not everyone does not like them, I use them extensively and I like them very much. I have to multitask and have muktiple projects at once and I use activities to separate them!

      Although, in latest releases somehow activities got buggier, I corelate that to enabling them in wayland.

      Liked by 1 person

    4. I guess by rewriting the whole Plasma Desktop, they could make kactivitymanagerd optional, but in my experience it is not a huge deal performance-wise, not even on a lower-end system with tons of activities, and it seems to be an integral part of Plasma, a lot of code would have to be moved around with who knows what result, so maybe it is better to just leave it, have one activity, and forget about it.
      Activities start hogging performance when you have a lot of them open at the same time, with windows in all of them, custom applets, custom wallpapers… All that resides in memory and the apps keep running in the background, hence the resource usage
      BUT… if you “Stop” the activities you are not using, they get cleared from memory and their processes are stopped, as if they weren’t even there. You can start them back up later, when you return to them.

      Like

    5. Yeah, I’m “content” with what I’m doing right now. There’s just something about the cleanness of just disabling something major you don’t use…

      But, this is quite a non-issue considering the time and resources available, so… it’s not a big deal.

      Like

  3. If you want KDE to be bug-free, you have to and must finally implement server-side retracing of crashes. It’s not easy at all to submit the crashes and new users can’t do this even if it was a life or death situation. Plus on Arch we can’t do that even the hard way, one has to reinstall and recompile all of the software just for symbols and pray to God to somehow reproduce again before the next KDE update.

    Like

    Reply

    3. It is a bit controversial though, just like KDE User Reports (the optional telemetry feature), there are some very vocal users who would not want any information to be shared without their explicit and one-time consent. Same goes for offline updates.
      Asking the user at install time is not an option, Windows does that and it is terrible
      Meaningful bug reports include an observed vs expected behavior, and detailed logs and system specs to pinpoint the issue. The first can’t be machine-generated, the second is considered private information that the user should explicitly consents to share, and the third is useless by itself.
      On the other hand, if there was an automatic bug-reporting feature, I would happily turn it ON.

      Like

    4. there are some very vocal users who would not want any information to be shared without their explicit and one-time consent

      We don’t do automatic bug reporting (and never will), which makes every manually-submitted bug report an explicit act of consent to share some information. Server-side retracing just symbolicates manually-submitted crash logs that don’t have symbols. There would be no data leakage or un-consented-to information sharing.

      Like

  4. Funnily enough we have the same criteria yet we often seem to clash on bugzilla 🙂

    >Something basic looks visually broken (e.g. “korners” bug)

    That particular bug fails almost every criteria.
    You even need to KNS to get that bug, for that reason alone it should be VLO.

    Criteria needs be stricter, adding more things to the queue isn’t the problem, filtering the most important things and then having a list where we have that mentality “this is so important I’ll fix it no matter how hard it is”. There are very few devs that do that.

    I’ve said before an ideal list should be around 10 items. If everything is VHI then nothing is. It’s at 56 and is losing effectiveness.

    Like

    Reply

    1. 56 is hardly “everything.” The list is already quite short relative to number of bug reports for all Plasma-aligned software (3,500) or all open bug reports in general (26,000).

      But there may be a bit of a communication issue here; this isn’t a “drop everything and fix this stuff!” list. It’s list of action items to realize a strategic goal.

      It sounds like what you want is a priority queue that can be kept very short. If you want, I can create such a thing and populate it with items from this list (or do the reverse, make a separate list and make the non-regression VHI bugs pull from it).

      Like

    2. > It sounds like what you want is a priority queue that can be kept very short.

      Yeah, “very high priority” if you prefer.

      >But there may be a bit of a communication issue here;

      Yeah. Your initiative sounds grand…the gripe is using the flag from an existing initiative for something that’s not quite the same and us muddying both in the process

      Separate would be good, you can use HI? – same semantics, but can separate 5 duplicates of a UX thing which is worked around vs tragic data loss.

      Liked by 1 person

  6. One think I just thought of, and I keep forgetting.
    The ability to remove the power / session submenu from kickoff, the legacy/classic ver.
    I have my own custom submenu (for specific reasons and scenarios), so it’s duplicated.
    And I could never figure out where this other menu is in the code.

    A simple cfg checkbox would suffice.
    Like kde4 I think had.

    Like

    Reply

  7. Hi,

    thanks for the update. I believe in heading 4 the “of” is supposed to be an “or”?

    Anyway, keep up the good work.

    Like

    Reply

  8. Hi Nate, hope you’re still reading comments to this post.

    I filed a bug report for Akregator which might or might not fit the “15 minutes bug” initiative but I think it’s so low-hanging-fruit that I should be able to contribute a fix myself.

    Since I’m not a C++ developer, could you or someone else point me in the right direction?
    E.g. a mailing list / forum / irc/matrix channel to subscribe to get help navigating the code?

    The bug report is https://bugs.kde.org/show_bug.cgi?id=434554

    Thanks in advance!

    Like

    Reply

  9. This is a clever initiative! Plasma should really move some effort from new features to bugfixes, and this is right in that direction: I like it! You are doing an excellent job.

    Liked by 1 person

    Reply

Leave a comment