Yet another KDE QA failure
Just as lot of people here and elsewhere keep on denying KDE QA major problem, the 4.10 release is yet another proof of how bad the situation is.
KDE cares so much that they already closed the bug with a oh-so-easy “not our fault”. Which is probably true, but still I consider that
- this shows a deep problem with how KDE tests releases.
- closing the bug is like telling their users “we dont care”.
- declaring the bug solved is wrong, it is not.
For example Gentoo handles this better by not closing their own bug, and trying to fix it, working with upstream (here, the Qt Project). Some projects care about their users, some not.
The irony there is that based on comments from this thread I had installed KDE 4.10 to give it another try and check if it was usable compared to when i gave up (~15 months ago). I tried from an new/test/empty account for fairness.
It was such a mess! No startup dialog, empty default panel and plasma restartint (aka crashing) very often. I mean RELIABLY crashing, not even randomly. My favourite way to reproduce is to try to add a system tray applet to the panel. I couldn’t have such a major component as the systray. Without systray, no way to get back half of my background applications, actually started but invisible.
But hey, having a working systray is so much less fun than having a webpage embedded in a plasmoid, dude.
Once I recompiled qt-core with -Os, which is the most reliable known workaround currently, things went a lot smoother, indeed, and all the obvious bugs/crashes from this 5minutes test were fixed. But what for a fix is that ? Not everybody is using Gentoo and can do that easily.
Don’t get me wrong, the bug is a huge one and it is not KDE’s fault. It’s a Qt bug, acknowledged as such by the Qt project and it seems to find its roots very deeply in Qt. We are used to see Qt bugs closed quickly, and the fact that this bugs is still not fixed is a clear indication of how difficult the problem is.
But come on, my setup is such a common one. Linux kernel, amd64, no fancy compiler, no fancy compiler options, the most standard system ever.
The KDE ticket was opened long ago (december 15th, during beta2), confirmed by several people on several distributions, and the bug was clearly identified as linked to Qt, so it was kinda obvious every distribution will be hit. This has been confirmed since then.
And guess what KDE did ?
Nothing, they released it as is, their conscience clear with the bug being closed. They do not have the notion of showstopper. Nothing new, we’ve known that since 4.0. Making things work is no fun, this should rather be distributions’ duty.
Post details
- Categories: Gentoo KDE
- Published: February 10, 2013
You may disagree on how KDE bugs are handled, but it is stupid to state that KDE doesn’t care about users. Most KDE developers care a lot about users. You are talking about a real problem but your rant is written in a provocative and unconstructive way and is unlikely improve things.
Shame on KDE. I mean, I’m a Gentoo user too and switched from Gnome to KDE from 4.4 times due to that ‘I-don’t-give-a-fuck-to-my-users’ attitude that Gnome had became like. Although I emerged KDE 4.10 yesterday and it’s running too smooth (excepting weird crashes on Dolphin when hovering over a image or video… wtf?), I read about those bugs you told and it’s very serious. And that attitude from KDE devs really piss me off: I was pissed off about that Aaron Seigo’s attitude about the damn stupid useless cashew on desktop (seriously, I bet neither he uses that moronic thing) but this is insane. I still believe in KDE project, it’s a great community and I thougt they care about their users. But this has no explanation. Hope they change their minds and see they’re taking things wrong.
Cheers bro, hope you neither loose your faith on KDE.
Hi.
It certainly is a serious issue, but I disagree with you in some points. The first, is that the status of the bug is marked as “hey, is fixed, don’t complain”. The way that the bugzilla keywords are used can be misleading, don’t take them literally, since is more complex than that. “resolved, upstream” are proper tags to describe the issue, IMHO. Is an upstream bug, and it has been confirmed that on the KDE side of things there is nothing that could or should be done, so there should be no more discussion in the KDE bug tracking system.
I can’t say that this is a “KDE QA failure”, because I can state for sure that I haven’t experimented such thing at all. If this is only hitting Gentoo users (and maybe OpenSuse according to the report), then is Gentoo who should do this simple thing: don’t put Plasma 4.10.0 on any stable release (if Gentoo has such thing) till the Qt Project fixes this important bug. But if we, users of other distributions or those who compile Plasma from sources can not even reproduce the bug at all, and experience a KDE SC 4.10 that is blazingly fast and stable, maybe there is no such serious QA failure.
And one last thing: if you are out of KDE since about 15 months, maybe you should consider removing your blog from Planet KDE. If you don’t feel like you belong to such community, that’s it.
I unfortunately have to agree with the quality of releases. There have been a few bugs which I’d consider release blockers, and they have been reported via bugs.kde.org, a few of them in plenty of different tickets even.
Such releases hurt the reputation of KDE a lot. Way more than delaying the release would. As much as I love KDE and as hard as this sounds, I sure hope that distributions and users are starting to oppose this and leave KDE, until the developers start to care again. Such a great software they create, but unfortunately completely lost the end user from focus.
I hope that distributions get a fix quickly (gentoo already pushed one to end users, which is more of a work around though. But still better than nothing), so that the end users are not that much affected. But still, this should be what KDE should be doing, not distributions.
IMHO, the only useful part of your post is
Don’t get me wrong, the bug is a huge one and it is not KDE’s fault. It’s a Qt bug, acknowledged as such by the Qt project and it seems to find its roots very deeply in Qt. We are used to see Qt bugs closed quickly, and the fact that this bugs is still not fixed is a clear indication of how difficult the problem is.
If someone who has a blog listed on Planet KDE thinks that KDE should have stopped the 4.10 release because of such an issue, I think that it is not unreasonable to expect that he/she suggests to make the bug a release-blocker, rather than writing such a blog post after the release has happened.
Please never forget the Code of Conduct. If you do, you are doing way more harm than good.
> (…) the fact that this bugs is still not fixed is a clear
> indication of how difficult the problem is.
Actually it looks like the bug is trivial. Apparently someone who wrote the buggy Qt code got a Qt internal API detail wrong and incorrectly used one function. Look at the fix: https://codereview.qt-project.org/#change,46616
FWIW, you are a KDE community member, and you even have a developer account with write access. That’s why your blog is on Planet KDE. And it’s also why I really don’t appreciate that “us vs. them” attitude you are taking here. For all intents and purposes you’re part of KDE, so its failures are YOUR failures as well. That’s what shared ownership and shared responsibility is about. If you perceive a problem in our community, you should focus your energy on fixing it from within, constructively, by lifting up your fellow community members. Not by taking them down and writing about “KDE” as if you’re a separate party. Or, if you prefer to be a separate party, please use your write access to remove yourself from Planet KDE.
I got a few hatred comments that I have discarded. Funnily, some of them very harsh, with links to KDE “code of conduct” as a conclusion. The “code of conduct” only contains common and obvious statements that I can only 100% agree with.
I don’t insult anybody and try to explain what lot of people have felt wrt KDE in the last few years. I got insulted at the name of this code. Weird times.
My post (and previous ones) shows that I disagree with some choices in KDE. It’s very far from “i hate everything and everyone and KDE”. I dont use KDE anymore, but I do use some very useful applications such as okular, okteta, gwenview, konsole, konversation, and few others. And I could name half a dozens of KDE devs that keep on impressing me, both for their commitments and the high quality of their work. But I dont want to get others jealous. Especially as I’m sure there are lot of very good ones that I dont know.
As I’m not as close to KDE as I once was, I tend to use the reviewboard if i ever want to patch something for example.
Actually, lot of people misunderstand what I say. It’s not “me vs KDE” as you say. It’s really more like a kinda inside point of view. There’s no hate, only hope. This is FEEDBACK, guys.
You’re a great guy, Eike, but sometimes you have a really weird attitude. KDE was released with a really bad problem around, someone points it out and you try shooting him for that? “Lifting up your fellow community members”? Sorry, what kind flowery nonsense is that? There’s a bug with a lot of comments, the right people have been aware of this for a long time and achieved – nothing.
This is not the time for declaring love for each other, organising another Woodstock and somking pot, “lifting” each other up but to roll up the sleeves and get this thing fixed properly.
Personally I don’t have a problem with a blog post that asks the question of whether we have a QA problem, or examines that issue critically. We have to be self-critical, after all. I’m just offended by the “us vs. them” thinking which I find highly inappropriate both in this venue (Planet KDE) and from a KDE developer account holder.
A better version of your blog post would have been a clean run-down of the situation, and a calm, non-accusatory study of what went wrong in your opinion and how we (we!) could have done better, and why. Something to spark constructive discourse, and perhaps affect positive change. It’s shitty that you got hateful comments, and that is certainly the responsibility of their authors, but it’s worth thinking about how you could have communicated your issue more effectively, with less provocation and vitriol, in the first place.
Wulf: I’m not shooting anybody, I’m giving Thomas some advice how he could have communicated his issue in a way that would have made people more likely to listen to his concerns, instead of making them feel attacked and demotivated, which is what happens. Preventing that should be in your interest as well, it seems. As for rolling up your sleeve and fixing the bug, rock on.
Thomas,
I hope you realize that it wasn’t KDE that closed out the bug, it was the bug reported (i.e. ME).
I even left a comment that we could track progress on fixing the bug on the KDE Bugzilla but that the proper resolution was (and still is) that it’s an upstream bug.
Given that I noticed the bug initially and left it alone from there you can probably point the finger at me for the QA if it makes you feel better. I never forwarded to Release Team or went screaming at the Plasma and/or Qt devs. Mostly because I have very little time to do stuff like that.
If someone were to take upon themselves the role of QA development I don’t think there’s anyone at KDE who would seriously oppose it. We know that we need better QA, but there’s no way to force people to volunteer for that instead of QA, art, translation, etc. If you have better ideas on how to motivate people to do so then we’re all ears…
(ou misread my post : this is far from being only gentoo/suse)
I keep on thinking this is a KDE QA issue. KDE released a software known as broken. They did not even mention on the release “beware of using this with current Qt releases”.
As said before, i’m only half “out of KDE” as you say, i keep on using some KDE applications.
Thomas: You’re still writing “they” …
I’d say the problem centers around “known as broken”. As an Extragear app maintainer I’m no stranger to shipping workarounds for Qt bugs unfortunately (as we need tend to be expected to support a wider range of Qt versions than KDE SC versions), sometimes for years, and I agree the SC should pragmatically do so as well, and perhaps even consider a release delay in such a situation. But I had no idea this bug existed, and I don’t get the feeling it was widely known. Perhaps we need better bug triage guidelines to make it more likely for such an issue to bubble up to the top. That’s the kind of stuff I would have liked to read about in your blog post, though, to start the discussion from _that_ place.
@Michael Pyne
I had not realized. Do you think the release team (or whoever decides upon releasing) would have made things differently if the bug was still open ?
At least you agree about the QA problem. Lots of people don’t and keep on saying KDE is almost perfect in this regard (hi Aaron!)..
Regarding the QA team (or lack of, i dont know the current status), I would even have volunteered. No joking. But you can guess how welcome I would be. And more importantly, there are points of view too much different for that to be worthwhile. Let me explain.
Some KDE devs and some users will think that the QA team is responsible for the bugs to happen and will blame QA for not fixing bugs. That’s not how I see things.
To me, there are two main purposes for the QA team:
* decide upon release blockers. If this list is not empty, their should be no release. This can mean fixing the bug, removing the corresponding module/program or find a temporary workaround.
* decide what can be merged. This is the point where there would be the biggest difference between what I think and what KDE devs think.
If i was in the QA team, things like plasma or nepomuk would NEVER have been merged, or at least not so soon or not that way. For example, maybe only the core of plasma would have been merged (panel, background). I very much like the idea of applets being very easy to write in whatever language you like and so on. This is very good for the ecosystem. But it’s also very dangerous, and I would have refused a design where any bug in any plasmoid can make the whole stuff crash.
I would have refused the changes where any konsole tab crash would kill all opened konsoles.
I would have refused the core KDE to depend on mysql, java or whatever stuff that should be there.
I could keep on. There are a lot of dependancies that are enforce at KDE and could easily not. Especially around nepomuk and kdepim(+akonadi).
For people like me using KDE applications but not KDE “desktop”, this last point is important.
For example, konversation does depend on kdepim, which brings the whole ugly kdepim+akonadi+weird daemons starting when you start konversation. All of this because there’s a feature where you can link irc nick to kdepim contact. I’ve proposed a patch to solve this problem, and this got accepted few days ago (hi to all on #konversation, and thanks again).
It’s not all that bad : gwenview for example did make it very well and nepomuk stuff can be disabled at compile time. (this time, this is Gentoo which did bad as they don’t allow this in the ebuild, but it’s another story).
@eike
I keep on saying “they” because if i say “we”, i got hatred comments and even hatred mails by people like Aaron saying “you’re not one of us” (which is ok) or “Who needs enemies when we have friends like that?” (Aaron, nov. 2009), which is less cool.
I agree with what you say though, I have a hard time trying to explain what i feel, and English is not my mother tongue. I dont know about you, but you seem to explain it better. Great&thx.
To be honest, what worries me is NOT that a bug like that is happening, but that noone really feels responsible for it. In the end, for a user it does not matter where exactly the bug lies- what (s)he sees is that plasma-desktop immediately crashes on login, and that KDE (Yes, KDE, not Plasma or some sort of frameworks) becomes unuseable for her/him. Pointing with a finger to the Qt repository and saying “It’s wrong there” is only of limited help. I myself have absolutely no clue about the involved code, but I would have expected for a problem with such an impact that more knowledgeable people race to provide a workaround as fast as possible until the real problem is analyzed and fixed. (And it’s not only Gentoo, I also have feedback from Arch, OpenSuSE, Ubuntu, and Slackware.)
I find some of your comments a bit weird, even contradictory.
For example you write that you are not using KDE software anymore, yet you list like half a dozen KDE applications as examples of things you are using in the very same sentence.
Andreas: That’s a good point. To offer an explanation if not an excuse, I think there might be some historical baggage exacerbating the problem there – Qt being a proper, contribution-accepting FOSS project is still a relatively new development, and KDE isn’t _fully_ used yet to assuming shared responsibility when stuff goes wrong in there. Qt used to be pretty much a blackhole, which accounts for some of the resignation when problems point to that part of the stack. We need to do more work on changing that mindset to one of “oh, it’s broken in Qt? Let’s fix it there, then” (although to be sure, this is already happening in many cases).
“There are a lot of dependancies that are enforce at KDE and could easily not. Especially around nepomuk and kdepim(+akonadi).”
Obviously it wouldn’t theoretically be necessary to have a package dependency of KDEPIM on Akonadi, however it would require some easy way to enable user triggered downloading of the package on request.
Do you know of any suitably cross-distro facility that can easily be embedded in an application that would allow KDEPIM applications to detect the unavailability of Akonadi and suggest its installation?
@kevin Krammer
You misread. I never said i was not using KDE programs. I dont use KDE desktop (plasma, menu, kwin, kdm, …). Once the desktop is removed, there remains a lot of very good stuff in KDE.
I think it is normal for 4.x.0 releases to have some problems. The number of beta testers can’t be compared to the number of users, so every major release is bound to have some misses.
If someone is annoyed by hiccups (small or larger as in this case) I always suggest to wait for the 4.x.1 release which is only one month away and up until now much better than the 4.x.0 release. Don’t get me wrong, new major features are great but small bugs are what make a DE annoying. With 4.x.1 you get both the great features and the almost bug-free nature of your previous installation.
That being said, KDE 4.10.0 is probably the best major release until now in terms of bugs imo.
This resolved upstream is something which has annoyed me in the past, too. Although it is technically correct, it sometimes misses the implicatations for KDE users. If it is a severe bug (causing crashes, loos of major functionallty, it should be evaluated, if there could be a temporary workaround put in the KDE code. Postponing release could also be a solution, if an upstream fix is on the way. At least the release note should contain a warning, if the problem is limited to a certain. setup.
This blog post may lead to something good after all. Maybe a lot of people feel the same as me, let me explain :
I’m a long term KDE user, with little experience in development, but I would like to help and I assume there are a lot people with a similar profile. Trying every release of KDE 4, I always felt frustrated because, it overall felt like an amazing project, full of energy and innovation, but it seemed that in the end, the overall experience was (depending on specific usage conditions) a more or less ruined by some superficial bugs or great but unfinished features.
There is no judgement here. I’m very very grateful of what the community did / is doing, and KDE is the only desktop project I still believe in nowadays. I’m enjoying 4.10 with no major issue in Kubuntu right now, but I really think something is missing in the QA departement. But the current developers / contributors / triagers / maintainers are already spending much effort so I guess something had to be rethought to get more people invovled :
-> how to make more “average” people like me contribute in a useful way ?
-> how to prevent KDE versions from being released as long as important bug are there ? I kinda agree on the idea of defining some release blockers and post-poning releases
-> like many “advanced” users, I spend a lot of time writing and responding to bug reports. But in the end, I have the feeling I waste the time of developers and triagers, because, eventually, it doesn’t seem to make a difference at all, there are tons of duplicates, and some bugs remain for a very long time (I receive some notifications for some bugs I reported more than / several years ago). After a while, I feel helpless and useless : that’s much energy that could be used differently. Of course, it also depends on one’s own motivation.
My conclusion is that, the KDE projects is achieving many goals already. We probably have the most advanced desktop environment and apps. But in the end, what really counts, is to be able to RELY on it, to have something stable. Which is why I know several people that are extremely impressed by KDE but don’t use it. Getting more developers etc. would be great, but setting up something to make the current community able to reach a higher quality, thanks to a different QA process and the help of the “silent mass of advanced users which is frustrated not to help” would probably have a massive impact.
… just my personal feeling : maybe I’m completely wrong.
While I personally don’t think this blog is the best way to express it, I can fully understand that there is some kind of frustration coming from “external” KDE contributors.
KDE has many talented developers and great people. It is however extermely difficult to even challenge some of the decisions, especially in the UI area. While the involvement of the responsible person(s) is high and valuable, the decisions can hardly be challenged and are just argumented, usually with great writing skills. An exemple is the introduction of the new “windows grouping” in the task bar which Aaron Seigo introduced in his blog. Each attempt to challenge the discussion and ask the author to at least accept the discussion and take the comments into consideration were abruptly rejected, sometimes even with ugly insults.
So yes, there is sometimes frustration among potential contributors. It is almost impossible to bring a new idea and even more difficult to bring critisism. There is no denying that some stability and usability mistakes happens and there is nobody to blame for it. That’s how software works and all developers aim to do something great. But the way the whole plasma thing has been advocaded (with talent) instead of trying to accept constructive comments definitely rebuts many potential contributors and leads to frustation.
This frustation could be easily avoided by using the mailing-list (kde-usability) to discuss new changes, instead of using blogs and social networks and writing odes to its own person…
The other idea, expressed by Thomas, is to have a real QA which has the authority to challenge the decisions taken by authoritarian persons.
Dear Thomas, while you may be correct in saying that KDE would benefit from a better QA process, the way you address this issue is really bad. But even though English is not you mother tongue, as you point out, you are doing a very bad job at communicating here. You can see from some of the comments (such as Eike’s) that there is quite a bit of goodwill among KDE developers despite your awful attempt at making a point. But the way you approach this will most certainly destroy any chance at bettering the situation.
In case you are not aware, the succession of arguments you make are these: “I told you what you are doing sucks, but you keep denying it. You don’t give a sh*t. This is how bad the situation is. You only work on stuff you enjoy, but that nobody needs, while you ignore the things we need. Oh, yes, it’s not your fault, but YOU DID NOTHING! That’s how much you care!”
What you should have written would have been: “This is the problem some users of some distribution experience. There is an easy workaround; this is the workaround. The bug is an upstream bug, but the bugs.kde.org label is misleading. Should we change that? In general, this is pretty big bug and it slipped the QA process. How could we improve the QA process in the future to avoid shipping with such bugs? What are the rules for a release delay? Would this have warranted one? Should it? I volunteer!”
The result could have been a new QA process. I one of the comments you even claim you would have volunteered. You would have had the chance to organize the QA process differently and play a role in making KDE even better. Instead, you wrote the rant I paraphrased above. I don’t quite think that you should be called an enemy (or worse) of KDE, but you surely did nothing to help. You really need to cool your head and improve your communication skills. And if you have so much hate for so many people in KDE that you cannot communicate without doing harm (I don’t know, I am simply speculating here), you might think about moving on. Surely, this way is not helping anyone. 🙁
Good luck!
@mutlu
You kinda miss one point : I think the problem is not technical, or at least not yet. The KDE team has been denying even the fact that there’s a problem, and this is what bugs me the most. According to them it’s ok and normal and there’s no problem. It’s so easy to hide behind such obviousness as “software always has bug”, “we do have a release process with 3 RC”, “fix it yourself, you bastard”.
I would agree with you here. There was a time, when I used to file bug reports and feature requests, directly on the KDE Bug Tracker.
After years, one fine days, someone would close it marking a duplicate of another bug, which was filed a month ago. If I was to draw some data as to which is the oldest pending request, it just got killed in some stupid bug triaging.
The KDE Bug Tracking process is one reason I don’t file bugs anymore.
I’ve always felt like something was fundamentally broken with KDE’s development process. With -every- big release there is always some show stopper bug or regression like this. Regressions happen way to frequently in KDE land and so over the years I’ve learned to avoid 4.x.0 releases like the plague. I always wait until 4.x.1 at least.
This is just an observation on my part. I’m not a KDE developer, just a user. I know that KDE is a huge project with lots of moving parts and limited resources, so I do not mean to understate the enormity of it all. But I think there is a lot of room for improvement in KDE’s development processes. It’s not all about adding new whiz-bang features. It’s also about doing it in a way that doesn’t break things for users.
There is a QA team within KDE and you are very welcome to join the effort. The QA team was restarted less than 1 year ago (I initiated it hence my intervention here) and it needs many more people. We already improved some steps and made bugzilla more handy but lots of work for QA is manual work which needs manpower. Reference for this initiative to build up a QA Team was posted on Planet KDE http://annma.blogspot.fr/2012/04/setting-up-quality-assurance-and.html last April and several dedicated people work on QA since then.
Anybody is welcome and any suggestion is also welcome and you are very welcome to join. Mailing list webpage: https://mail.kde.org/mailman/listinfo/kde-testing and is waiting for your contribution.
I hope I addressed everything regarding the QA Team and for sure we need people like you, able to test and report and triage and make your point about blockers and help device a better QA procedure within KDE.
I would like to emphasize the progress we made already after starting the QA Team: as several people noted, 4.10 is quite a good release and the QA effort already paid of. A big thanks by the way to all people involved in testing, triaging, marking regressions, to distributions packagers and testers, to the KDE sysadmins for implementing the continuous build, etc.
@annma
As said in a previous comment, I’m afraid QA (imho) is not only about testing and triaging. Testing/triaging is important and heavily needed, of course. No doubt about this.
But QA is also about politics. I’ll give only one example and wont speak about plasma/nepomuk, people is too much sensitive about those. Let’s consider akregator. Have a look at akregator CODE and tell me how it is even possible that this ugliness made it to an official release of KDE (or kdescwhatevernameyouprefer) ? And how is it possible, once accepted, that it remained there ?
Bugzilla is not even capable of telling me how many (open) tickets are related to “akregator”. It gave up at ‘500’ it seems. This is what we mean when we say “we are fed up of reporting bugs, this seem useless”.
Those, (imho, still) are two very good examples of non-triag/non-testing QA decisions that were made very wrong
* minimalist peer-review : i guess any decent coder wont need more than 20 minutes of digging into akregator code to be very confident that it should not be accepted. But of course, it’s all about politic, and there’s the obvious “KDE needs this”, “KDE needs more”, “gnome has xxx”, or whatever. QA should not endure marketing decision and be only about technical merit. This is hard to achieve, I agree. I hate politics.
* I guess there should be rules like “any subproject with more than 300 tickets opened for more than 3 months is removed”. Either the project is too buggy, or it is unmaintained, or very probably just both.
See my point ? This is more than testing/triaging. QA is also about REFUSING stuff (peer-review). I’ve always felt that KDE was about accepting anything. Especially in the pre-4.0 area. The context was different I think, and I remember there was some kind of ‘fear’ about having a lot less coder than before, and 4.0 never going out. I might be wrong. That’s in this kind of context that you need a strong QA. Strong as in “not overwhelmed by marketing/fear”.
And QA is also about KICKING OUT bad stuff. Projects can go bad, or maybe it was an error from the beginning to accept something. Just remove it. It’s no easy decision, people will get angry. And if some well-known KDE dev is kinda involved in the project it can get really messy, i know. This is difficult, this is what QA is also about.
If as a project manager I was given responsibility over such a big project as the whole “KDE”, this is the first think I would do. Cleaning/pruning projects. It would need to be done slowly, carefully, but with strength.
I suggest you subscribe to the mailing list and you start a discussion here. I am not sure who you blame for “politics” and as I said we are aware there are more things to do on the QA side and we are aware “it’s not only about testing and triaging”. My comment was about clarifying for you the current QA effort and clarifying we welcome anyone and we sure welcome you, especially as you have QA expertise.
I am a bit surprised by the way you misinterpret my comment which clarified the QA Team current status and invite more people to it. If you feel some program has to be removed, just ask for its removal in kde-core-devel mailing list. I personally asked for stuff to be removed from KDE in the past or to be not included in a release. It’s perfectly normal to do so. There’s no single “project manager” for KDE software, everyone interested in taking action is free to do so.
Anyway, I look forward to work with you.
Ironically, Akregator is an application I’ve been using essentially daily for the past seven years, and it’s been a reliable companion for me, and overall a pleasure to use. It’d have been a loss for me if it hadn’t been accepted just because it doesn’t fit your personal QA criteria.
It’s worth nothing that FOSS development is volunteer-driven, and it’s releasing software to users that gives new volunteers an incentive to contribute to development, either because they are users themselves, or because they can see that their contribution would have real value to real people. Not releasing software fails to provide that incentive, and so ultimately fails to get development done. This is why “keeping things unreleased until they’re perfect” is a difficult proposition, and why QA is a special challenge in FOSS.
I heard MTP required for Android devices 4.1.1 and later got yanked out of KDE 4.10. Also, some bugs that have bothered me for years (ie: 293687) are still being reported present in 4.10.
It looks like the taskbar wiget is going to be completely rewritten in QML so maybe bugs like 293687 will go away on their own, but i half expect some other bug to take it’s place.
IMO, it really looks bad that confirmed bugs last through half a dozen major releases of KDE with no fix in sight. It would be nice if some of those confirmed bugs would at least get noted in the release log of kde if they’re still present.
https://bugs.kde.org/show_bug.cgi?id=224447
Another example of a bug that slips through release after release and has countless duplicate bug reports.
David: Fix is near, look forward to the in-progress QML rewrite of the Task Manager widget.
>If as a project manager I was given responsibility over such a big project as the whole >“KDE”, this is the first think I would do. Cleaning/pruning projects. It would need to be >done slowly, carefully, but with strength.
That went really well suggesting that on something completely broken a year ago
http://osdir.com/ml/plasma-devel/2012-06/msg00260.html
@bumble
Yeps, and this is a nice example of QA (hi again Annma!). Though… you know, I think KDE has some really bigger problems than those two buggy applets (or are those plasmoids ? sorry i’m lost again).
Hi all,
I’m a long time kde user and very minor contributo with (nowdays, but who knows) unused dev write account.
I see reason in both camps and I understand both good and bad feelings. We are all humans and humans have feelings about stuff they care for.
My 0.02€ added to the conversation is a question: what is a KDE (SC) release?
From my point of view it is the release of sources a DE that are known to work on some set of libraries, OS, etc (call it linux distribution).
So, (still from my point of view), it is correct to mark a bug as resolved (in KDE’s b.t.) if the bug is not in KDE source.
If a library/OS bug affects KDE sources it should probably be cited in release notes accompaining binary releases, but I don’t see why it should block the distribution of the (correct/working) KDE sources.
As many told, in the past the KDE project got a lot of harm from binary packages beeing distributed without checking if they where really working or not (I’m a Kubuntu user, a satisfied one, but I had some problems in the past).
So maybe an apptempt to solve the problem could be:
1) Try to ensure that the code works well on at least one platform before releasing it as part of the KDE (source) SC (this is ehat the great QA team is doing just now)
2) Try to help distributions to avoid packaging broken binary packages
Of course I guess the hard part is the second point.
Ciao
Vincenzo
@vincenzo
In this very case, the bug was not in KDE, but KDE released something known NOT to work on all major distributions and this is NOT distribution’s fault. As is very often in KDE history, they kinda put the burden of testing/fixing bugs on distribution’s shoulders.
Do the bug exist in older version of qt? If not way should they not release? I suppose many of the more stable binary distros use older qt version.
Beside that. I use the 4.10 in Arch Linux. Why is my installation not affected of the bug? Is the bug only triggered on some computers? As I understand it booth my qt version 4.8.4 and my CXXFLAGS for qt should trig the bug.
Matter in fact. This is probably the mayor kde update after kde4 with fewest problem for me.
@josef
I have no clue about this.
Actually this blog entry is not about debugging this issue, there are tickets for this (links in the main post).
I have to say that I don’t quite understand your post: You’ve identified the bug as a bug in a released version of Qt, yet you’re claiming that KDE’s QA processes are broken? Be that as it may, your conclusion seems strange to me.
Also, you say that you do not feel part of the KDE community. In that case, it would be appropriate to not have your blog on planetkde. I can do that for you, if you agree.
@Sebastian Kugler
Is that some kind of troll or what ? I’ve detailed in the blog post that I’m not complaining about the bug. Bugs happen. The problem i’m speaking about is the fact that KDE shipped a release known to be broken on all major distributions. How unclear to you is this point ? i said explicitely “THE PROBLEM IS NOT THE QT BUG” and you stay with the official “but the bug is in qt” ? You’re typical of the kind of behaviour that i’m reporting on, very often found in KDE dev : for you, users are just stupid and it’s not even worth reading what they say/report, you already know how stupid they are. Denying problems and saying it’s user’s fault is found all over the bugtracker.
Please stop playing the victim Thomas – you’re not a martyr for the users, because _you are not a user_. You have a KDE developer account. If your point is lack of assumed responsibility, then you’re in the same boat, because you haven’t taken any responsibility yourself. I don’t read your name in that bug ticket. I don’t see you having reopened the ticket. I don’t see you raising the issue on the release-team mailing list. I don’t see a patch from you for either KDE or Qt to fix the issue. What did _you_ do, given you had the means? Man in the mirror, dude?
And FWIW, knowing Sebas quite well, I take issue with bullshit like “for you, users are just stupid”.
It’s not meant as a troll, just to get that out of the way.
Even reading it three times, I don’t really understand your point, especially the causality you’re trying to create here does simply not parse for me, your choice of medium seems to be more geared towards creating public pressure, rather than fixing the problem. Others have pointed out as well, that, as a developer, we expect not just shouting from the sidelines, but actively working on fixing problems, and at least dealing with them in a productive way. Maybe that’s me being dense, maybe that’s your blogpost which seems to come mostly out of frustration rather than the desire to go about this in a productive fashion. Fact is, your dealing with this issue is not helpful, and the bug you mention seems to be much more of a fringe case than you are making it out to be. (It maybe *exists* in all major distros, but in that case, nobody noticed it. Feel free to prove me wrong with a bunch of pointers to recorded bugs in different distros, they might contain useful information.)
You mention other commenters pointing you to KDE’s Code of Conduct, which you seem either unaware of, or are ignoring purposefully. That’s just not what works for our community, hence my question: Would you be OK to remove your blog from planetkde?
@eike
I’m not a KDE dev. I did some very small patches and that’s all. That doesn’t make me endorse the whole responsability for not having done heavy tests, does it ? You might know Sebastian very well, and he’s probably a very fine guy. But still, my post was about pointing a problem with KDE QA and he keeps repeating “it’s Qt fault”. So ok, he doesn’t take think users are stupid. Maybe only me ?
@sebastian
I can say it again but i really feel stupid doing so : I think that KDE shouldn’t have shipped a release known broken on most distros. I really feel like stating the obvious. It seems to me and quite some others that a lot more energy is put into denying bugs and problems, and explaining how dumb users are, than to actually do dev stuff. I can understand “bug confirmed, but we don’t know how to fix it” of course, or even “can’t reproduce it here”. But not this kind of behaviour.
See this recent example (probably not the best one, but it got fixed lately). See how it took several years to fix such an obvious bug, how it took several years to be just confirmed although there were lots of duplicates. Check how this guy “Dario” keeps on saying “You’re stupid, just disable it if you don’t want it”, though the very ticket title is about “disabling doesn’t work”.
Ok, I think I got it now. 🙂
You are comparing Gentoo’s bugtracker (and workflows) with KDE’s. Where in Gentoo, bugs in “other projects” are being tracked, they are not in KDE (just marked as “this bug is not in codebase of this issue tracker, has been reported elsewhere instead”).
That’s comparing apples and oranges, however. I suppose it makes sense for Gentoo to track upstream bugs (they are a bug in the product Gentoo ships, and won’t be resolved without further action, a pulling in a bugfix update from upstream, for example).
For KDE, that’s just not the case. It doesn’t make sense to track, triage or comment on the bug in KDE’s bugtracker, that should be done in the corresponding upstream (or downstream) bugtracker instead, to keep information in one place.
Of course it’s easy to dismiss this subtle difference as “QA failure”, but then you entirely dismiss a pretty important portion of understanding and acknowledging why that happens. It is in fact not a “we don’t care”, but a delegation thing, pretty important and natural to an open system such as the Linux ecosystem.
Besides that, I don’t assume all users are stupid (there’s probably some among them, as is the case with humans), but please don’t put such words into my mouth, it’s quite personally offensive, and I don’t think there’s any sane reason to blame me of that. That’s just a lack of basic respect.