Over the last months I got the feeling that lately my mail folders related to “user issues” are not getting flooded any more. Now feelings are always very subjective, so I wanted to check whether there is some truth in my feeling. Over the same time I noticed that there is much more trolling against KDE for example on the dot.
One of my mail folders is for new threads about KDE in the German ubuntuusers forum. I have received notifications for new threads for quite some time, but the mails get deleted automatically. So I asked Christopher Grebs whether he could provide me the required information. So here is a plot showing the number of new threads per month over the last few years. As it is an (k)ubuntu related forum we can expect higher number of threads in April and October.
I included the year 2007 as it was the last year with only KDE 3.5 which many users seem to praise as the best desktop environment ever without any problems. What we can see here is that the number of new threads in 2007 (average 154) is similar to the one of 2009 (average 168) while 2008 was clearly a year causing trouble to our users. Kubuntu shipped 4.1 with 08.10 and there is a huge increase in November.
But what is really impressive is the decrease in 2010 and even more in 2011. So my feeling was right, there are less new threads. In fact in 2011 (please note that there is still half a month to go) the average new threads are just 63, which is less than half of what we had in 2007.
There can of course be many reasons for that. Maybe ubuntuusers is not any more so popular, maybe users go to forum.kde.org which did not yet exist in 2007, maybe Kubuntu is no longer a popular distribution for KDE users.
But it could also show that either KDE lost many users recently or that our software became much better, much better even than KDE 3.5 has ever been.
Now I thought how can I verify that this is not related to the forum in question and for that I wanted to look at our bug database and wrote a small tool to generate some statistics (if anyone is interested in the raw data please send me a mail). So here I present the number of opened bugs per month for KWin. As opened bugs I mean bugs which are either still open or have been fixed. Duplicates, invalid bugs, etc. are ignored.
Here we have a slightly different picture. Given our release schedule we expect higher numbers at end of year and mid of year. 2007 with KDE 3.5 hardly had seen any new opened bugs till the beta of 4.0 came around. Unlike in the forum 2008 is not the year with most reported bugs. KWin did not enable compositing till 4.2 (January 2009), so it was for most early adopters just the same as the 3.5 version. We can clearly see the enabling of compositing starting at end of 2008 with the high peak after the release in February 2009 and constant high values throughout the year. But already 2010 showed less newly reported bugs and in 2011 again my feeling is correct. Currently the curve is below the one of 2007 and the average is close to 2008 again (16 compared to 17 reported bugs per month).
Now this are two datasets validating my assumption. So let’s have a look at a third one: the number of opened bugs per month for Plasma. Here it is important to know that Plasma’s bugs are not as nicely triaged as KWin bugs, so it is likely that the number of bugs is just too high.
Here we can see the same as in the KWin case: 2009 was the high bug year and 2010 and 2011 much less new bugs. In 2011 we have an average of about 82 bugs/month compared to 80 bugs/month in 2008. This is an even more impressive trend than for KWin given that Plasma is much bigger and new concepts such as Netbook shell and many more applets were added.
Now given these datasets we can clearly say that our users find less bugs in our software. The only remaining question is whether this is caused by less problems or less users. For a source-code only distribution project such as KDE it is difficult to know how many users we have and we have to notice that very often the only feedback we get is the negative one. So it is difficult to say whether there are users with no problems or no users. But also for that question we can ask bugzilla:
This graph shows us all reported bugs against KWin including duplicates. The interesting value is the “Intel Peak” in May 2011. This driver bug affected Kubuntu users with Intel GPU and enabled unredirection of fullscreen windows. So although it only affected a subset of users and DrKonqui recognized the duplicates it’s the fourth highest value for the complete data set resulting in 2011 seeing almost as many bugs reported as in 2010 (832 vs 806) with still a big chance of 2011 surpassing 2011 as in each year more bugs have been reported in December than in November. We also see the problem of the Intel bug going away with the Kubuntu release of 11.10.
Now I generated some more graphs which show us some more data. Here we have a complete graph for all bug data of KWin over the time.
Again we clearly see the Intel Peak both in the reported Bugs and Reported Crashes. In general we see very nicely the DrKonqui induced bug reports. Whenever there is a peak in the reported bugs, there is also a peak in the reported crashes.
This we can also see in Plasma. It is quite clear that very few crashes affect a large userbase. As with the case in KWin these can be upstream. E.g. I’m quite sure that the last peak in the graph has been caused by a change in Qt 4.8.
Impressive is the beginning with all bugs being more or less fixed instantly during the development. There is one more interesting thing to be seen. Twice a year Aaron starts to panic about the number of opened bugs in Plasma and I think we can see this here as well. Let’s have a closer look at the fixed bugs:
Quite an impressing work the Plasma devs are doing there. Overall I think these graphs validate that there are less bugs and it shows how our software has matured over the years.
I suppose the obvious response is the old quote that there are “lies, damned lies, and statistics.”
One reason for fewer bug reports is that users have given up reporting them because experience tells them that there is little chance of anything getting fixed. A prime example is Knode where a bug report said a feature wasn’t working properly. The response seems to have been to disable the feature completely. Various complaints about that dysfunctionality have been ignored over the years so what is the point in complaining.
Kmail2 is a disaster area but the KDE team appear to think all is well. Not that all of the problems are with the new version; several irritating bugs I’m seeing in my latest trialling of it date back to the old kmail. The same goes for the address-book and calendar functions in Kdepim.
KDE isn’t alone in this. There are bugs in Thunderbird that were first reported last century and are still awaiting a fix.
As I say, perhaps the users have been taken over by apathy.
This is something I doubt due to the Intel Peak. It’s showing clearly that users report the issue if it hits them. Also if we look at the bugs getting closed in Plasma and KWin we see that it is clearly not the case that developers don’t care about the bugs. That there are bugs which don’t get fixed or where a feature gets completely removed is quite normal for every software project. Not every bug is fixable, sometimes features are just too broken to be maintained.
Martin, If features are too broken to be maintained, I wish the someone would say so on the bug reports. Ignoring the comments appears to the user to be very rude.
Over all, I guess I’m happy with KDE, I suppose it’s just Kdepim that’s driving me – and many others – up the wall.
Anyway, I think I’ll go away and resurrect some old bug reports or, if I can’t find them, raise them again. And, of course, add some new ones.
Cheers, Graham
at least for KWin we try our best to comment on each bug report. It’s something I consider as important as well. The user took the time to report the bug, so we should take the time to reply to it. Unfortunately that seems not to be possible in all cases. Some products are more or less unmaintained (think of kopete for example). So there are also no developers who could reply. A very unfortunate situation to be honest.
“Kmail2 is a disaster area but the KDE team appear to think all is well. Not that all of the problems are with the new version; several irritating bugs I’m seeing in my latest trialling of it date back to the old kmail. The same goes for the address-book and calendar functions in Kdepim.”
I just use kdepim and im not a contributor. However, I follow its developmet and I clearly see that you’re wrong.
kdepim developers know about shortcomings. They are working A LOT to fix it. It seems to me that kdepim is the most active project in KDE at this moment where several people are actively improving it.
KDEPIM is very huge. It might take a while for it to become as stable as the rest of KDE. (Although, I have very small issues with it from the master and im happy with it)
Kde is really stable now. I’ve been using 4.8 beta version and the only annoying bug is the kmix one. Oh and I can’t use Opengl 2 shaders but I disabled it so it’s not big deal.Thank you for all your hard work. You are awesome 🙂
Although it is true that the stability of KDE has greatly improved, I wonder if the lower number of bug reports is not mostly due to having less users. It used to be that KDE had about 70% of linux users, but that was before Ubuntu and KDE4, so now, I expect the number to be closer to 40% (which is bad as I think KDE is the best hope for the linux desktop).
On the other hand, the number of linux users over the period might have increased 50% (these are somewhat random numbers, based on http://www.w3schools.com/browsers/browsers_os.asp) so we should expect a slight increase of the number of KDE users.
So I hope what those stats show is more an improvement in software quality and less a lower user count.
If the number of users would have decreased due to Ubuntu we would not have seen the strong increase in new bug reports in 2008 and 2009. If a product is buggy (and KDE was at that time) and you switch distributions then you don’t report bugs. On the other hand if the user base would be connected to Ubuntu we would expect an increase in 2011 after the switch to Unity. Just think about the “success” of Linux Mint. Users who switched to Ubuntu due to an unstable KDE would probably have switched back to KDE after the Unity release.
So I think that the numbers are completely unrelated to Ubuntu. Personally I also think that Ubuntu is much less popular than people tend to think. Look for example at the Ubuntu One user count – that is not impressive at all.
Those stats roughly correlate to the historical Kubuntu experience. However, the horror period couldn’t all be laid at kwin’s door, many KDE lovers were forced to other distros as a result. For those who can’t exist without apt debian has hardly filled the gap, is debian sid still on kde 4.6? Sheesh! Happily, the last few kubuntu releases have been extremely well done. Kudos to all involved. Hope it’s the start of something big.
In my experience, kde indeed has matured over the years. Of course, there will always be new bugs (e.g. when switching from 4.6 to 4.7, the sftp:// protocol didn’t work anymore when a password entry was required, which almost drove me mad, but I “google-found a workaround”) and things that just won’t get fixed, but I really appreciate this desktop environment and prefer it over others for how configurable, feature-rich and nice-looking it is. I can really adapt it fully to my needs, and though I’ve considered and tried alternatives (and liked how fast they start up!), for me, kde remains the DE of choice.
In my experience KDE has matured a lot indeed, and the fact that the open buglists do not always show that is beause of loads of backlog that may or may not have ben fixed by now, but are probably too minor, or outdated. Or it is so overly often duplicate (e.g. flash in konqueror) that developers don’t bother anymore.
There are a bunch of statistics that I find useful to look at: The growth rate of open bugs, the ratio between open bugs and submitted bugs (over a period of e.g. half a year), and the number of open bugs that have not been commented on in, say, the past year.
For plasma, we normally see a high growth rate, we see that the current open number of bugs is half of the number of reports per half year, suggesting simply a good turnover rate. The number of outdated bugs however is at ~60% way too high. This means that a) a big back log, but b) not enough people fixing bugs to keep up. Many of these bugs seem to be in fringe plasmoids and such, but still: Stability in plasma needs more people right now.
KWin has a open/new bug ratio of roughly 1, and the amount of open bugs is very stable, but also a high amount of old bugs. Meaning: Somebody needs to clean up the list, but then the devvers should be able to keep up with the bug reports. In that sense, kwin is stable indeed.
Amarok is an example of a perfectly stable project, with an exellent bug squad: The number of bugs is stable, and the turn around ratio is very small. Kopete and Konqueror are projects where the number of open bugs is so high, but stable that I wonder whether anyone really cares about bko.
In my case I simply no longer file bugs, they tend to get ignored. So it could be that you get less bug reports because people are simply tired of trying.
example: I just had nepomuk crash several times. I don’t feel like installing debugging symbols, afaik what went wrong is not logged. I’m not filing a bug because it’ll get ignored. A kde crash/kill has caused the desktop background not to be saved if it was changed, even successfully. I’ve been dragging around tabs in chrome and got like a half popout and had my kde desktop freeze up (but ctrl+alt+backspace still kills) sometimes it’ll unfreeze. But not reporting because frankly my bug reports are too often ignored. In Arch (note: I don’t report kde bugs here I report them to actual kde bugzilla) a 2 year old request to get the default password hashing algorithm to sha512 just got fixed. When it takes 2 years to get 1-2 lines changed in a config file for a better default, why should I bother filing bugs in kde? I know bugs in KDE that weren’t fixed for like 7 years, and were seemingly even ported into KDE 4.X. The screensaver bug was reported in what? 4.0? 4.1? it’ll be 4.9 or 4.10 before it’s fixed? and now all the screensavers need a rewrite…
Also, I’ve previously been very annoyed at how KDE has presented it’s close rate statistics, because it consistently shows “closed bugs”. I only care about “fixed and implemented” closed shows dupes, won’t fix, need more info, etc. So KDE bends the stats to show the reality it wants to show, instead of breaking it down in a way that might honestly reflecting fixing of things.
not all bugs are easy to fix. You see we need a rewrite of the complete screen locker layer to be able to fix a bug which has been present since 4.0. We don’t ignore them, it just is a lot of work. I spent several weeks on fixing this one annoying screen locker bug. You need the time for it.
I’m aware of that. I code Perl, hopefully someday KDE/QT will have Perl bindings again (noted in progress but not done). But I just got a request for a bug claiming “it’s 4 years old and kde3 can you still reproduce?” seriously, don’t wait 4 years to ask me for more info; and distributions make it difficult to get a good BT (which is why I like logging in my apps)… Also keep in mind I’m not just talking about Kwin. I respect the work you do as being hard to downright impossible. “set TERM to support 256 colors” https://bugs.kde.org/show_bug.cgi?id=212145 I’m willing to bet that I could now source dive and supply a patch, because it’s 1 line of code somewhere… but frankly it’s so easy it should be a “yes or no” and done next release if yes. This has been completely ignored.
Also, I heard KDE got a test suite, sometimes I think it’s not heavily used enough… maybe there needs to be a KDE testers just like CPAN Testers. More tests tend to mean more stable code.
Don’t mix bugs and feature requests. The bug you posted is a feature request. Those get often just ignored or are considered that users who really want it should implement it.
*) Taking ubuntu one user accounts as estimator for ubuntus success isn’t a good idea. (How many mac users have a mobile me account?)
*) Could you provide more integrated measurements? Like the relation between “total posts” vs “total kde related posts” on ubuntu users forum?
*) google trends for “gnome,kde” strenghens my suspicion: KDE isn’t as big as it used to be. Although I don’t think users left kde it seems as if new users rather connected to gnome.
If you can not make graphs, then you should ask for help, really. So many lines are confusing, it seems you are tying to hide something.
Now it is number of bugs vs months, with many curves for the different years.
Better is number of bugs vs time, with only one curve.
thanks for the offer to help? Where should I send you the spread sheet so that you can do the better ones?
Hello,
on my machine KWin & XOrg often hog the CPU. I would file a bug but with no info other than “it’s slow” I don’t think that it would be very useful. I tried to google around to see if there’s a way to profile KWin but to no avail. I would like to help but I need some direction here. Can someone give me some advice on this? Or should I open a bug nevertheless and ask for help there?
Leo
This is a user support issue. Try forum.kde.org