This week we of course continued the customary bug-fixing, but got some nice new features and UI improvements too!
For many weeks, the development speed seems to have drastically stalled. Why is this happening? Have some sponsors reduced their workforce contributions to KDE?
Maybe just the end of the year?
@ezh, what are you referring to? I’ve not noticed this.
No new major features, bug fixing count is low as well. Starting with latest week:
94 KDE bugs of all kinds fixed over the last week
119 KDE bugs of all kinds fixed over the last week
106 KDE bugs of all kinds fixed over the last week
129 KDE bugs of all kinds fixed over the last week
143 KDE bugs of all kinds fixed over the last week
107 KDE bugs of all kinds fixed over the last week
137 KDE bugs of all kinds fixed over the last week
138 KDE bugs of all kinds fixed over the last week
181 (!) KDE bugs of all kinds fixed over the last week
73 KDE bugs of all kinds fixed over the last week
115 KDE bugs of all kinds fixed over the last week
149 KDE bugs of all kinds fixed over the last week
A weekly report of a certain part of the KDE product portfolio (in this case Plasma) is not necessarily a reliable sampling technique.
Developers can and do move between various aspects of KDE, contributing to applications, libraries, Plasma components, and so on.
Sometimes this is very visible when name is mentioned in “This week in Plasma” as well as “This week in KDE apps” or in other combinations.
Depending on the time within a product’s release cycle there can often be cases when development activities on something take longer than the news cycle. For example if a feature takes a couple of weeks to implement.
These will only appear as “activity” in the week the work got finalized, not in the reports in between.
Then you have work which can consume large amounts of development resources without immediately resulting in anything that might make it into a weekly summary.
For example untangling code from an application into a library, refactoring or modernizing code, extending test coverage, and similar sort of things
Of course orthogonal to that there can also be fluctuations in developer availability, again for a wide range of reasons.
This is particularly the case with the Union theming project, which is taking up the time of 1.5-2 engineers and not producing anything reportable on a weekly basis. Once it’s done, it’ll be amazing, and reported of course. But yeah, large projects that aren’t finished yet are inherently going to be under-reported.
This represents something interesting. Plasma is a mature product at this point in time, so almost all the low-hanging fruit has been picked already. This means there aren’t as many “quick wins” people can bang out in an hour which will then get reported in these posts. There are still some, but the number dwindles. Rather, the remaining work tends to require large projects
About the battery charge cycles label, it’s a nice info to have but I’m not sure it’s clear to some users that a battery has “charge cycles” (and they may be thinking that a battery looses heath with the time, not necessary the usage), and since a “cycle” doesn’t refer to a battery being charged from empty to full, users can be confused that cycles add up even when they use their laptop mostly connected to power outlet.
Also, since there is no unit for cycles, users may not know if 10, 100 or 1000 is a lot of cycles, and if the number of cycles may reduce the battery health linearly.
Maybe a tooltip next to cycles (or health) explaining that a high number of charge cycles would reduce the battery health (and hence, the battery life) would be less confusing. This tooltip could also be changed when the health the low to suggest the user to change it.
Otherwise, it’s still a pleasure to read KDE progress every week.
PS: The fix for “wobbly” text is great news for a 125% scaling user!
@ngraham, on that note, I found conf.kde.org/event/6/contributions/206 recently, but wasn’t able to watch the replay of the event, since the URI (https://live.kde.org/playersite_0a5de95e-0f2e-4479-8d59-d0095df9daf0.html) is 404. Do you know whether these are published anywhere?
@Mixmax, I agree. Without a unit, it really is meaningless for me (upon first glance).
It was streamed live on Youtube: https://www.youtube.com/watch?v=bovuuPZxWC4&t=15038s (bad video quality, but audio is ok).
“All bugs are not created equal” would definitely seem to be a major factor in raw “counting metrics” like # of bugs closed decreasing over some period of time.
One other factor to consider as well is, as Plasma matures - especially working through the growing pains of adapting to Qt6 and all the upstream Qt bugs and downstream packaging bugs that have cropped up - I think one would expect that the number of bugs being created would also decline.
That does appear to be trending to be the case since the Megarelease, with spikes that do occur in bug creation trending along with distribution releases:
So even if all else were equal, there would be some degree to which fewer bugs going in would mean that there are fewer bugs that can be closed.
If it’s well implemented, the cycle count is read from the system firmware or battery fuel gauge, and what the unit is depends on the fuel gauge firmware. Hopefully it’s full cycle equivalent, and doesn’t tick up every other time the current changes direction.
Li-ion batteries are complicated, and what counts as “a lot” depends on the chemistry. They also do lose health with time even without any charge/discharge, especially at higher temperature. You can handwave something like 500 cycles being a place most batteries should be able to get to in the absence of abuse or manufacturing defect, but there’s no hard rule, and “health” is probably a better indicator if the fuel gauge is reporting it from a fancy-pants degradation model that incorporates impedance spectroscopy (internal resistance vs frequency vs state-of-charge).
The way I see it, as long as the laptop doesn’t die at 20% when the health says the battery should be good, that’s already pretty impressive.
You can find all Akademy 2024 videos here:
obligatory “maliit is neglected and a massive accessibility issue” comment.
@aronkvh, do you have any idea why the quality on https://www.youtube.com/watch?v=bovuuPZxWC4&t=15038s is so poor in comparison to 2024 - Kockatoo Tube!
I’d mention this at 2024 - Kockatoo Tube, but AntTube shows “Cannot access to the remote resource”, and the instance itself isn’t open for registrations.
iirc the same videos are uploaded to both sites, youtube just likes to compress things.
I am able to interact with Kockatoo tube from other Fediverse accounts, so that is probably a problem with the server you use.
That’s not it. Akademy venue this year had low bandwidth available unfortunately so live uploading had poor video quality.
Still the recording was done as usual and uploaded later to peertube.
We are hitting bugs that are more difficult to fix now.
There are things that can take literal weeks to fix.
Any help is welcome and appreciated, however! 
Unfortunately I’m not a programmer. 
But I do my best in funding KDE (150 € this year), reporting bugs & promoting KDE in social networks.
Where can we downloads the slides (not visible in the video)?
