I’ve started to worry that mentioning really small weird bugfixes week after week gives the impression that KDE software is buggier than it really is. The truth is that all responsibly maintained projects are constantly landing these kinds of maintenance bugfixes, so it’s probably a bit misleading to be talking about them all the time.
Instead, I’m going to try only mentioning the big, consequential bugfixes: the ones for bugs marked HI or VHI priority, that have with multiple duplicates, that are really significant in effect, etc. Hopefully this should improve the signal-to-noise ratio in the blog posts.
I’ll still mention new features and significant user interface improvements, of course.
Let me know what you think!
Adventures in Linux and KDE 
Sounds fair to me!
LikeLike
Aah, probably for the best! I have to admit I tune out of most items because it’s just too much stuff.
However, I think you could still have a count of all bugs fixed.
LikeLike
The blog is already showing a curated list of bugfixes; a true weekly count is easy to get simply using a Bugzilla query, but would it be meaningful? Many bug reports aren’t describing user-facing bugs per se and are instead about internal tasks, developer-only bugs, CMake issues, etc. Tons and tons of this stuff is always happening, but I doubt folks are interested in most of it.
But if you are, check this out: https://bugs.kde.org/buglist.cgi?bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&bug_status=RESOLVED&chfield=bug_status&chfieldfrom=2022-08-03&chfieldto=2022-08-10&chfieldvalue=RESOLVED&list_id=2130124&query_format=advanced&resolution=FIXED
That’s a list of all the bug reports that became RESOLVED in the past week throughout all of KDE. It’s 112! Already much more than what I was reporting here.
LikeLike
I think this link should be put in the end of every “This week in KDE…” blog post with the title like “A detailed list of all fixes landed this week”.
Therefore, there will be no need in going into much detail wrt small and minor fixes right?
LikeLiked by 2 people
Yep, I’m going to try that.
LikeLike
Actually, I liked that because due to that I got a feeling that lots of stuff is getting fixed (it is probably because I use Latte that crashes quite often that I experience KDE as buggy – it also recovers from the crash superbly – so I would expect there to be tons of bugfixes). But it is not a big deal. Maybe less info but with a bit more coverage would be better, as I often have no idea what got fixed.
LikeLike
sounds good. Not everyone understands that it is normal for such a huge community of open source projects to have many bug fixes every week.
LikeLike
I think this is the key. I need to communicate this without trying to blast people with a firehose of information. Because you’re right: tons of bugs are being fixed every week, more even than I could report here even if I wanted to. As long as it’s understood that there’s activity and KDE is alive and well, I don’t think it’s so important to focus on each individual thing.
LikeLike
I was thinking the same a few days ago, agreed.
LikeLike
law of unintended consequences: this will lower 1. contributors who are just starting and want their name there. 2. users who actually understand bugfixes are common.
also, it will not help make it be common, as it should.
sometimes joining them is not the right way, it is just defeat.
LikeLike
It’s a shame, because I liked reading about all the small but fixes – for one, it gave me a sense of churn (in a good way – people are doing good stuff), and as a person who is interested in KDE and it’s success, but doesn’t have the time to invest in being really into the state of KDE bugzilla, your reports help me discover features I wasn’t aware of, behaviours that are interesting and things that I can try.
Since I’m running on neon unstable, I can often test immediately the things to report on, so that is also a nice experience for me – but that is probably not relevant to most readers…
LikeLike
For me it shows an active development 😉
Thanks for writing week for week.
LikeLike
> For me it shows an active development
For me, too! Good news each week!
LikeLike
I’ve always enjoyed seeing all the bugfixes, as they feel like a reassurance that there is lots of current development activity and energy. But I can see how some people don’t understand it the same way, or how others may even unscrupulously use that transparency against KDE. Maybe seeing all the little bugfixes is what perusing a changelog is for.
As an aside, take my opinion with a grain of salt- followers of your blog are going to be skewed towards wanting to see what has been on your blog.
LikeLike
I think so, yeah.
LikeLike
The age of the bug would also be interesting at times. Fixing a regression that no “stable release” distro user ever encountered might be less interesting than fixing a bug that has been there since KDE 3
LikeLiked by 1 person
IMHO the opposite is true: The more you focus on more important bugs, the more you may make people believe, that there are bigger problems. I think, everyone here knows that every software contains bugs and that mentioning bugs – or better: their fixing -, independently from their importance, is more a sign of an open minded community.
Kind regards,
LikeLike
My thoughts exactly. Additionally, I thought the blog posts were about what the author finds interesting. Focusing on something specific for other reasons sounds like a potential recipe to grow tired of it.
LikeLike
Well, like it or not, this blog (or at least the “This Week in KDE” series) isn’t just my personal playground. People care about it and rely on it for news. Other folks in the Linux community mine it for information. So the presentation is important.
LikeLike
Unfortunately, there *are* bigger problems–a lot of them. My desire here is to show people that we know about them, care about fixing them, and are making steady progress towards doing fixing them. Ultimately the big problems are the ones that people care most about about getting fixed. Little tiny papercut bugs are present in all software, and fixing them is good and shows forward momentum, but my worry was that they were being unnecessarily emphasized compared to the bugs that really matter.
LikeLike
I really like the full set, because it really gives me an impression of how much work is actually done and how much attention to details is paid. Furthermore, I like to pay attention to new changes, after upgrading my system. Thus, I pay special attentions to areas of WIP, since its the best time to report bugs, start discussions, etc.
I think this series was always about detail for enthusiasts. When you just like to new the big change the release pages of plasma release pretty much give a good summary.
I also recognised the other side of people ranting about the bugs like in the the phoronix forums, but I guess there are many people out there just waiting to nag on something. Maybe this is some strategy to push their software of choice and try to eliminate other projects that drag resources away from their community. So I do not think we should give in to them.
LikeLike
I’ve been reading literally every line of these blog posts so I find it a bit of a shame.
LikeLike
Nate,
There are arguments to be made both ways on this.
Personally, I like seeing the bug fix count and the gory details of the fixes.
I know it would be more work for you but would it be possible to do both formats for a month or two, letting people see both. Then, have a poll to see what the end users would like to see on a weekly basis?
LikeLike
Perhaps what I can do is highlight the big important bugs in the main test, but provide a link to where people can see the full list of all bugs fixed over the past week, to preserve that sense that things are happening, that there’s forward momentum.
LikeLike
I think that would be an excellent middle ground. It also allows people to adjust to the new format and adjust to reading information in new places.
LikeLiked by 1 person
I think it’s a good decision but ultimately what’s causing the perception of KDE being buggy are long-standing bugs such as with monitor layouts. On X11 my monitors layouts always reset back to default. On Wayland one of the monitor repeatedly stops getting updates. I need to disable and re-enable it.
I swear, since KDE4 was released it’s just one annoyance after another. At the end of the day the features of KDE win over the annoyances but I would never recommend KDE to a non-tech savvy person.
And also bugs such as some weird stuff being able to crash the display server is an indicator of the code not being written with defensive programming.
And display server crashing on Wayland kills everything … when I reported it is a bug it was described to me as a design decision. Despite KDE listing this as a show-stopper https://community.kde.org/Plasma/Wayland_Showstoppers#KWin.2Fcompositing.2Fwindow_management
I did not want to be all negative. KDE is awesome. It’s just not high quality software.
LikeLike
The multimonitor bugs are really bad, yeah. We have basically reached the conclusion that the fundamental approach taken in Plasma 5 is unsalvageably incorrect and are working on something that will be massively more robust by design.
LikeLike
That’s very good news ! Is it something we can expect for Plasma 6 ?
LikeLike
Hopefully for Plasma 5.26 or 5.27!
LikeLike
Even better ! 🙂
LikeLike
As someone that recently switched back from Gnome largely thanks to these posts I’ll miss all of the detail but hope it makes your life a little easier. 😃
LikeLike
Sounds reasonable to me. What I think some here don’t realize is that listing all these small corner case issues that most people never face ends up as ammo elsewhere online for toxic DE trolls. I read through every single bugfix in the release announcements anyway.
LikeLike
As a downstream packager for Debian I find the detailed list extremely useful. I use it to backport some high profile fixes to our packages before they are released, to cross check with Debian bug reports (or the simple fact of having heard of some fixes will ring a bell when we have a corresponding Debian bug report). Also it gives a nice overview of what’s going on in KDE land and gives me motivation to work on the packages.
LikeLiked by 1 person
The bugfixes that will show up in the “Significant bugfixes” section will be the kinds of fixes that you’ll want to backport, so all will hopefully not be lost. 🙂
But ultimately you shouldn’t be relying on my blog for this (what if I get hit by a bus etc). A bugzilla query looking for newly fixed bugs will probably serve you better here and have much better coverage that what I post about on this blog. I already don’t cover tons and tons of KDE apps that could benefit from backported fixes.
LikeLike
In general, I enjoy reading your weekly list of fixed bugs (and I want to express my thankfulness once more for your weekly work of compiling all those interesting things together! ☺ ).
If you want to keep the “Next week in KDE” series more compact, the bug fixes list could maybe be reduced to plain links to the respective reports, together with their title. At least for me that would be equally sufficient.
If there are bug fixes that are particularly “spectacular” (long standing/hard to debug issues, many affected users etc.), they could get a more detailed mention as of now.
LikeLiked by 1 person
Yeah I think I may end up doing something like this.
LikeLike
I enjoy every bugfix and every post of yours. Don’t mind if they are minor.
LikeLike
It sounds to me like your blog is now getting a wider audience and is turning more and more into a public figure of KDE. In that regard, focusing on the bigger changes sounds reasonable.
But I am part of the group of people that will miss the detailed bug fix list very much (and as one commenter mentioned above, I have made my first contribution to KDE in part for getting my name in this blog). Maybe someone, if not Nate, could start a different blog to track the tiny fixes that are also important to make KDE the environment we love ?
LikeLike
I like reading these weekly reports. Perhaps some of the stuff I don’t find that interesting but bits of it are & I understand other bits will be interesting to other people. I hope the above hasn’t been overly influenced by the Phoronix forum where ngraham often posts answers to; it isn’t the best of forums in terms of being childish flame wars for one desktop vs another & moaning about “all the bugs not being fixed yet” level moaning etc. I hope the above isn’t a reaction too much to that & this change isn’t a case of ‘playing to the lowest common denominator’. If users/fans/hobbyists of a proportionally niche techy area of interest aren’t grateful for Nate’s nicely presented interesting weekly updates then they can read something else. However, I’m happy enough if Nate wants to streamline things to make them easier for himself.
LikeLike
I also like the current format. But if your blog is mined as you say and there is a risk to be misunderstood I also get it.
As a developer I sure prefer to see bug churn than silence because the one indicates health and the other death of a project.
But who is gonna read about KDE progress that doesn’t understand the simple above fact?
LikeLike
Similar I think the “Fixed bug in Wayland session” gave a wrong impression about the quality of the Wayland session. Especially as all other bugs were not marked as “Fixed a bug in X11 session” or “Fixed a bug affecting X11 and Wayland session”.
LikeLike
In fact, when a bug only affects the X11 session, I have generally prefixed it with “In the Plasma X11 session…”
But it was the same thing with me wanting to show progress on the Wayland session. At the time I started, the Wayland session was an unusable buggy mess. Now it’s nearing stability parity with the X11 session, and has already exceeded it in features. So maybe it’s not so important anymore to prove to people that our wayland story is good. Then again, I’m disappointed that more distros aren’t shipping it by default yet. Only Fedora KDE, to my knowledge.
LikeLike
That’s probably for the better. I would love to see a summary before a point release and major releases as well, as while the weekly review shows a good amount of progress, I feel like I lose track of the notable changes that could use more spotlight right before they get their release.
LikeLike
I liked the smaller bugs, because once in a while, the small one was an important one for me. On the other hand, I understand, that you may not have enough time to keep the present blog formula.
However, the reasoning that the number of mentioned bugs keeps the appearance of Plasma being buggy – you are soooo wrong! Those who read your blog, have complete opposite feeling – that we are in good hands, that the issues are worked on, that we can submit bugs, and they won’t be ignored, that the Plasma is developing even if we don’t see the major results. Because of that, this won’t be an entirely good change. But I understand that you need to refocus yourself and refresh the blog’s formula, maybe for time saving reasons?
Anyway, it’s clear you are a bright and flexible, so I’m not worrying that such a decision will be kept blindly if it turns out to be a bad thing. Time will tell. Good luck.
LikeLike
The small bugs are interesting, and demonstrate attention to detail (which is what really polishes a desktop).
I’d suggest sorting them by impact:
— major,
— minor,
— cosmetic,
and list them in that order.
LikeLike