February 10, 2013
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.
@Sebastian (18:45)
Nope, i’m afraid you missed the point again. My post is not about comparing bugtrackers and how projects use those. I’m comparing how (at least in this case) gentoo dev DO care about users : they track the problem, try to find a solution, and of course wont release anything to users until the problem is fixed. Not that the problem is NOT from gentoo’s, but they still to care. Their purpose is to have something working for the user, not to hide behing “not our fault -> ticket closed”. Check comments there and on bugtrackers : users are shocked by this behaviour.
@sebastian (19:18)
This remark of mine was not done blindly but based on your comment. You said “it’s a qt bug why do you complain” why my whole post was (trying) to explain that I hugely disagree with this behaviour. You know, freedom of speech and such. I was not unpolite or whatever, just expressing my opinion.
And this remark of you show shows a huge lack of respect for this. I’ve spent some time explaining why/how i disagree with this and you just come here and repeat it again as if i hadn’t say anything. I feel offended.
You could have come and say “I read your post, but i disagree”, but you prefer just repeating the point i’m arguing against. Without any new argument. Have you even read it ?
It’s exactly as in this ticket : it seems dev dont read the report and just assume that the user is stupid enough not to understand that it needs to click on “disable”. COME ON the bug report is a little less stupid and it’s no wonder a lot of people are reporting it.
@Thomas
<>
You are my hero. I wish you were on some kind of KDE equivalent of the Debian ftpmasters.
The problem with the “coders-rule” or meritocracy method is that coders will naturally tend to give their code special treatment, like parents do to their own children when compared to how they treat other children. Code that is not ready for primetime will be pushed out so that it will get “wider exposure” to “help fix more bugs faster.” These coders–perhaps intentionally, perhaps not–end up getting free QA labor from end-users who just want software that JUST WORKS.
The end result is that software quality–the actual, released software–suffers, and therefore users–real people with real lives who need their computers to JUST WORK so they can USE them and GET WORK DONE–suffer. There is endless churn as half-baked software is pushed on unsuspecting users who click the Upgrade button when they see the desktop notification that there are 97 upgradable packages. There is needless frustration when, after innocently upgrading, software starts crashing, leaving users with little to no recourse (downgrading is a huge hassle even for experienced users).
And the end result of that is people go back to Windows or Apple. And that’s a real shame.
Who am I to talk? But I will call it like I see it: developers need to recognize their software as both a PROJECT and a PRODUCT. Unfortunately, all too often the product aspect is neglected. After all, developers are used to running nightly builds and dealing with broken things here and there. But users are not, and few are willing to put up with that. Developers (in general; I’m not indicting everyone) need to change their attitude toward releasing software. There needs to be a no-tolerance attitude toward releasing known bugs (at least, serious ones!).
Until this attitude changes, the “year of the Linux/FOSS desktop” will forever remain but a dream.
Two more comments:
1. The point of this blog post is very simple: KDE should not have released 4.10 until the bug was fixed or a workaround was in place. No matter how true that it’s an upstream Qt bug, the fact remains that it affects KDE software and KDE users. Debian would call a bug like this (one that causes crashing of the primary UI, sometimes even on login) a Release Critical bug, and it would block release.
To release 4.10 with a serious known bug like this, KNOWING that end-users will get crashing plasma-desktop and an unusable DE, is simply irresponsible. Expecting distros to shoulder the responsibility of working around it is simply passing the buck.
2. I am as much in favor as anyone of only speaking words that build others up. The tongue holds the power of life and death.
But I am also in favor of pragmatic software development, of getting to the point, which is fixing bugs and not shipping broken, buggy, regressive software.
I am disappointed by people who keep saying “Code of Conduct or go away!” and “Let me delist your blog for you!” instead of discussing how to prevent this kind of problem from ever happening again. It distracts from the more serious problem of, in this case, users whose GUI crashes on login.
As an example, I point to the kernel. I don’t endorse the way Linus sometimes goes off on people, especially publically, but look at the product of the kernel project: it has few regressions, it gets better with every release, and breaking userspace software is not tolerated. The software–and by extension, the user–comes first, and little time is wasted on politics or hurt feelings. Someone who makes a completely valid, insightful point about a real problem in the software or the development process is not dismissed or attacked because someone was offended or thinks he wasn’t nice enough.
This is the problem with having a Code of Conduct governing online, interpersonal interactions: it can be used to silence people who point out legitimate problems. It makes it easy for people to be officially offended by perceived violations of a canonical niceness rulebook. It makes it easy to proceed directly to the “Code of Conduct violation! Go away!” response instead of having real discussion. Rather than helping people develop thicker skins, and helping people learn how to get along, it justifies being easily offended, and dismissing, rather than resolving, conflicts.
Food for thought.
@adam
Funny that you mention the linux kernel. Ten years ago, I used to say that most free software code was crap but two projects stood out in term of design and quality of code : the linux kernel and KDE/Qt. Ok, you can remove drivers from the kernel, i speak about the core kernel. Nowadays, Qt has lost some of this praise I had, but is still very very much ok. I still consider the kernel as a very good example of nice code and nice design.
And my blog post is less about this very problem and more about “guys, you/we have a huge problem with how QA is done in KDE”. this was just an example.
It’s hard to decide between “you” and “we”, because for either of those, I got flames from KDE devs. They are very concerned by things like “you”/”we”, KDE vs KDESC, denying bugs and such.
Ah! Those good days when KDE was ruled by code and design!
Aaron just called this blog post “atrociously bad blog entry” and i feel offended, but it’s not the first time Aaron offend me, publicly and privately. The only “bad” thing in my post is that I mention a problem with KDE, and suddenly 10 KDE devs want to ban me out of kdeplanet.
KDE doesn’t like critic but likes censoring. Amazing and frustrating to see how KDE has changed 🙁
At least, some KDE devs agree that there’s a problem. Most users do, but who are they to have an opinon ?
@Thomas: “KDE doesn’t like critic but likes censoring.” is totally hilarious considering (a) we allowed your blog to remain on Planet KDE despite being a _very clear_ Code of Conduct violation and (b) _you_ are the one publically, repeatedly admitting to censoring your blog’s comments.
@Adam: Re, “To release 4.10 with a serious known bug like this, KNOWING that end-users will get crashing plasma-desktop and an unusable DE, is simply irresponsible.” – you’re driving this discussion backward. We already established that this bug wasn’t widely known within KDE (and FWIW nor does it have as broad an effect as you seem to think; I haven’t seen or heard about a single crash on Fedora, for example), and the discussion had advanced to considering how that info flow could have been improved. But you’re not really interested in improving, I guess – just venting your frustration.
Eike,
After reading the KDE Code of Conduct, it seems like your comment is a violation of it, since by accusing me of “driving this discussion backward”, and being “not really interested in improving, I guess – just venting your frustration”, you are violating the “Be respectful” section which says, among other things, “In a disagreement, in the first instance assume that people mean well.” You have done the opposite, instead assuming that I don’t mean well. And it seems like most people are assuming that Thomas does not mean well, which is also a violation of the revered Code of Conduct. Obviously we mean well, because if we didn’t care about the quality and success of KDE, we wouldn’t be spending our time here.
The Code of Conduct also says, “We value tangible results over having the last word in a discussion. We defend our core values like freedom and respectful collaboration, but we don’t let arguments about minor issues get in the way of achieving more important results. We are open to suggestions and welcome solutions regardless of their origin.”
Despite that, I see much resistance based on the origin of these ideas and minor issues such as how they were worded. I don’t see results being put first.
Regarding the seriousness of the bug, it’s been reported to occur on at least Gentoo, Kubuntu, OpenSuse, and Arch. You say you haven’t heard about it happening on Fedora. Does the almighty Fedora invalidate the users on these other distros? What does it take to qualify as having a “broad effect”?
It’s debatable whether the bug was widely known within KDE. I would argue that if even one official KDE developer knew about plasma-desktop crashing in the 4.10 betas or RCs, it was widely-known enough that it should have blocked the release, or at least have been discussed as a potential blocker. In hindsight, it clearly should have been.
So, let’s talk results. I’m not a KDE developer, merely a long-time user and advocate and bug reporter. I don’t know what the KDE release process is like, but it seems fairly obvious what is missing. Is there a simple, straightforward way for someone to report a potential RC/blocker bug and have it officially reviewed before a release is made? If not, why, and how can such a process be instituted? Is there any kind of automated way to get a report of crash bugs and review them before making a release?
Most importantly: is there anyone with the authority to say “no” or “not yet” to releasing code as an official KDE release? If not, I think there should be one or more people with such authority. Do you agree? If not, why? If you do agree, how can this be done?
And please do remember: we mean well or we wouldn’t be here. Try to set aside feelings and be pragmatic. It would be great for KDE if the motto was, “It’s all about the users.”
@Adam: I really don’t appreciate all the attitude, all the putting-words-in-others-mouths, all that stuff. Why do you need to add colorful little bits like “the almighty Fedora” or suggesting that I’m saying it invalidates the user experience on other distros? That sort of stuff doesn’t signal “I’m trying to work with you”, it signals “I care about being right and about provoking you”. A lot of this thread has been about how KDE engages with others; I submit that the way you engage with others isn’t a whole lot better. But let’s move on.
Here’s my argument all along, condensed: I consider it unfortunate that this bug wasn’t given the attention I agree it deserved. I’m wondering how to do better next time.
> I would argue that if even one official KDE developer knew about plasma-desktop crashing in the 4.10 betas or RCs, it was widely-known enough that it should have blocked the release, or at least have been discussed as a potential blocker. In hindsight, it clearly should have been.
I disagree that this is a realistic release target. Software crashes for many reasons, many of which its developers can’t do anything about. It’s not practical to stop the release process cold over just any crash report without spending some time figuring out _why_ things are crashing and how many people are affected. Unfortunately that means sometimes this awareness only materializes after a release has already been made, as happened here. The goal has to be to improve our performance in investigating and classifying bugs to minimize this disconnect, but it’s improbable we’ll ever eliminate it entirely.
> Is there a simple, straightforward way for someone to report a potential RC/blocker bug and have it officially reviewed before a release is made?
Bugzilla offers facilities for this, but to _my_ knowledge (and anyone from the release team should feel welcome to correct me on this) our discipline in using them as part of the release process is relatively poor. That said, there is the relatively easy way of suggesting a bug block the release on the (public) release-team mailing list. As far as I can see (as an external observer much like you by the way; as mentioned earlier I had never heard of this bug before this blog post), this didn’t happen here because there wasn’t sufficient awareness of the bugs’ magnitude in time.
> Is there any kind of automated way to get a report of crash bugs and review them before making a release?
Sadly not, and this has been a recurring discussion in the KDE developer community over the past year. Many feel that crash reports filed via DrKonqi should no longer go into Bugzilla, but rather into a separate web app that would offer better facilities to gain an understanding of for example how wide-spread a crash is, and also allow Bugzilla to be used more productively by reducing its noise level (because data you can’t chart/poke into easily enough is just noise). That means such web apps need to be evaluated or perhaps created, which requires time and manpower. We’d love you to help out, the respective teams in KDE are quite open.
I trust you’re a regular reader of Planet KDE if you found this blog post; you’ll also have read posts on such topics then.
> Most importantly: is there anyone with the authority to say “no” or “not yet” to releasing code as an official KDE release? If not, I think there should be one or more people with such authority. Do you agree? If not, why? If you do agree, how can this be done?
Yes, the release team has the authority to decide on a release delay. I agree it should have that authority. However, these questions allude to a bigger theme of how strictly to adhere to the time-driven release philosophy – a philosophy we’re currently culturally locked-in to a degree, because we absolutely had to adopt it to get KDE 4 out the door (because as I explained earlier in this thread, there are competing pressures in FOSS development of getting releases out the door to mobilize new contributor manpower). This “it’s cultural” bit is hugely important, and at the end of this comment I’ll come back to that with a little reflection, and, frankly, some frustration as well.
Now, in terms of release QA, here’s a couple of thoughts and ideas loosely floating around in my head that I’d like to toss in (and I’d appreciate it if you could keep the “they’re punting responsibility again!” impulse in check for the moment):
– One problem we have with release QA stems from the fact that KDE is decidedly distro-neutral and doesn’t do packages or run its own distro, which means we don’t have an established test platform to use for end-user experience testing. We sort of rely on the distros for that last mile right now, which means certain QA issues more or less naturally are detected during that stage of the pipeline. This is unfortunate in the sense that it’s a stage uncomfortably close to end-user delivery, but considering alternatives is a quite tricky probem (and as usual, creating those alternatives requires manpower).
– Something I’d like us to try is to have a release checklist with test scenarios, and make releasing conditional on passing that checklist. The way I’d love to see that implemented is by having a web app that anyone can sign into to participate, get half a dozen test scenarios to try with an RC, and report success or failure, and then we only release if we have a certain number of success reports for every test scenario. This would allow us to gamify the process and involve people more – “Want to see the new KDE release? We’d love to, but we don’t have enough test reports yet, help us hit those numbers!”. Fedora release QA uses a similar approach which seems to work quite well for them. The problem, again, is that it of course requires manpower to set all of that up.
—
Now, back to culture: See, the thing is, you’re dealing with a community here. If you want to change how a community operates, e.g. how it feels about time-driven releases, that requires a _discussion process_. You don’t convince anyone by acting like an asshole and saying “but my POV is _obvious_!”; your objective is to _convince others of your POV_. If it’s not obvious to them, _that’s the challenge you have to rise to_. It’s met by engaging them positively and giving them time to see your POV and wrap their heads around it. And that’s why this blog post and much of the comment thread below it is so shoddy: It’s in denial of the realities of how communities and humans actually work, it’s not trying to engage positively in a venue we’ve created for that purpose, and it’s self-absorbed. There’s bits like “if I were KDE project manager” in there earlier that had me grimmace painfully: Oh boy, does that guy not know how providing leadership actually works. It’s about motivating people to get stuff done, not just playing gatekeeper. KDE isn’t a faceless entity, it’s just people.
@adam
I like the idea of “code of conduct”. But there, those people just use it as a (very weird) way to deny our right to express politely what we think. It’s a kind of artificial diktat. I still don’t see why this piece of text would have any right to deny my right to speak.
And of course, I _hugely_ agree with your last statement : we do mean well. It’s even more frustrating not to be understood. I’m not one to loose time on something I dont care. I see a huge problem with a project i once loved, and I try to explain what i feel. Sure, some people dont like critics and will do anything but understand that it’s an act of love.
Hey, nice thing to say on february 14th 🙂
As a outsider I really don’t get why you cry because the rest of the KDE dev did the same thing as you. Apparently the bug is not that big problem on most of the binary distros. At lest I don’t find anything when I google it (and it’s working okay on booth my computers I tried 4.10 on). Apparently Gentoo is affected of the bug. As I understand it, you are booth Gentoo and at least in theory Kde dev. Why do you write about it after the release, why didn’t you do anything earlier? Especially as I get the impression most of the devs not running gentoo never was affected as much of the bug.
Great, there’s really nothing i was hoping to hear. Not denying the problem is already a huge step for KDE. If the problem is not denied, I’m sure more people would be happy to help.
@eike 17:42
I likes this comment of you. More constructive than just insulting my post and saying how irrelevant is the opinion of a user.
I kinda disagree with the “scenario” part, but it’s just that… “kinda”.
I think the problem with QA in KDE is not something that will be solved by even more tools and even more administrativia. My POV is that it’s a human problem. I’m really borderline there with my English skills and I dont know how to express it. It’s something like “KDE devs are arrogant and this is what should be changed”, but less rude. I’m gonna be lynched again for saying so, but i’m getting used to it now.
[Warning : this is how I’ve felt it, i’m not saying it’s the whole truth]
I think that at one point in its history (around 4.0 release, ~2007-2008), KDE had both a huge ‘human ressource’ problem (not enough manpower, as every free software project) and a fear that the project was not “up to date” with latest technology trends. The goals for KDE 4 were too high and the team was having a hard time reaching them. Meanwhile, the time was running and the motivation tumbling. Some choices were made : merge this all and release a not-even-half-finished project. I know there were discussion about this and I remember the arguments for doing so : more or less the project was about to half-die and this was a compromise so at least things kept on going. Which is debatable.
But even since then, previous stuff was not fixed, and lots of things got added/merged. Without any review (or not enough) because KDE needed to have everything and more. Dare I say it ? it got bloated. Yeah. It’s not as if it was very original for such an old and big project. Any dev knows that the risk is to get bloated. But it got bloated nevertheless.
KDE was accepting anything because it was missing contributions so much that the “barrier to entry” was lowered.
My opinion is that if you lack human ressource, instead of doing so, you should instead FOCUS. Keep the number of projects low. Lower the barrier, why not, but not too much. Keep a safe minimal quality. But this required a psychological step : accepting this fact. That’s difficult and why I often use the word “denying” when speaking about the KDE dev team.
To get another example than nepomuk or Plasma, let’s talk about kdepim. For a very long time, the team was almost empty. I’m not blaming the kdepim team. I know they were few (if ever) and did what they could. But they could not do enough. So what ? Just give up. Either remove the whole kdepim or trim it to the strict necessary. Why keeping on breaking everything trying to do the ultimate abstract kpart-based integration stuff known as ‘kontact’ when all applications were already broken enough ? Huge goals help motivating people, i know. But when it’s too high, it hurts, too.
I tried to keep on using kmail even when mails were unreadable, attachments were saved as 0-byte file and i got 10 crashes a day. I really tried. I reported bugs, i even tried to fix bugs because it was a very important tool for me (of course, dang! we are speaking about EMAILS). But I had to gave up.
I could point to lots of places in KDE where the code is ugly, very often over-designed and spaghetti-lookalike. I know it because there’s quite some places in KDE that i had patched locally. Or tried to at least. I’m not here to say “this part sucks” and even less to say “this dev sucks”. This is not the point here. The point is the QA process.
And yes, there are parts which are still really ok. OF COURSE. I think the more you go into core (kdelibs / kdebase) the better the code is.
Every now and then, some KDE developer has a great idea about some very abstract/profound design he thought about during his shower. He writes a blog entry and start breaking everything in the source control. If the developer is young, inexperienced, and only very recently joined KDE, even better. And of course, most of the time things wont be finished and some half-finished very-good-idea will be implemented and buggy.
Everybody knows the way to prevent this. Get senior dev take some responsibility over every part of the project, strong enough to refuse unfinished stuff. Do things like ‘branches’ and such when developing those great ideas. And merge wisely. This is very hard to get right and requires senior dev to decide. It needa be finished, maybe a little buggy, but only with small bugs known to be easily fixable. Not with profound design mistakes.
As said, I’ve stopped watching KDE development for the last, say, 1.5 years. So what i say is what i was feeling by then and might have changed. Nowadays, i only see the ‘result’ and not the process. Based on this, it doesn’t seem like it has improved a lot.
Also, KDE is so big, I’m sure there are parts where those things are done well, and others not. Those dumb enough to still think that “KDE sucks” is my only opinion be damned. If it was, I would just say “KDE sucks” and be done.
Eike,
> I really don’t appreciate all the attitude, all the putting-words-in-others-mouths, all that stuff. Why do you need to add colorful little bits like “the almighty Fedora” or suggesting that I’m saying it invalidates the user experience on other distros? That sort of stuff doesn’t signal “I’m trying to work with you”, it signals “I care about being right and about provoking you”. A lot of this thread has been about how KDE engages with others; I submit that the way you engage with others isn’t a whole lot better. But let’s move on.
> You don’t convince anyone by acting like an asshole and saying “but my POV is _obvious_!”
I don’t wish to debate this to death, either, but you’re being somewhat hypocritical here. You are the one calling names. I didn’t put words in your mouth; I quoted you. And as far as I know, sarcasm isn’t forbidden by the Code of Conduct. I simply used it to make a point, one which you avoided by complaining about how I said it. Don’t you see the irony in saying, “You don’t engage with others well, asshole”?
> I disagree that this is a realistic release target. Software crashes for many reasons, many of which its developers can’t do anything about. It’s not practical to stop the release process cold over just any crash report without spending some time figuring out _why_ things are crashing and how many people are affected. Unfortunately that means sometimes this awareness only materializes after a release has already been made, as happened here. The goal has to be to improve our performance in investigating and classifying bugs to minimize this disconnect, but it’s improbable we’ll ever eliminate it entirely.
I’m not asking for perfection, but I think this bug should be a wake-up call for KDE. Anytime a user clicks the Upgrade button and ends up with a desktop that crashes on login, it’s a major failure. Whose fault it is is beside the point. These are the kinds of problems that drive potential users–and contributors!–away. Please don’t shoot the messenger. (And if there even needs to be a messenger, that’s another problem!)
I’d still like to hear more about the awareness issue about this bug. Since it was reported while it was in beta, what more is a bug reporter supposed to do?
> Yes, the release team has the authority to decide on a release delay. I agree it should have that authority. However, these questions allude to a bigger theme of how strictly to adhere to the time-driven release philosophy – a philosophy we’re currently culturally locked-in to a degree, because we absolutely had to adopt it to get KDE 4 out the door (because as I explained earlier in this thread, there are competing pressures in FOSS development of getting releases out the door to mobilize new contributor manpower).
Not to rehash the whole KDE 4 debate again, but if your theory is, “We have to release broken software so people will want to help us fix it,” I simply disagree with that philosophy. (N.B. By “release” I mean “publish it as non-alpha, non-beta, non-RC, finished software.” It’s perfectly viable–and guaranteed to make fewer people frustrated and angry, which discourages participation–to release unfinished software as “alpha” or “beta” and still attract interest.) Not only do I think the idea is incorrect, but I think it’s bordering on disingenuous, because users–real people–try to use it and expect it to be usable; and then they become disillusioned and give up. I still see people saying that they avoid any x.0 release because they expect it to be buggy–and if that is not considered indicative of a major development process problem, then that indicates a major philosophical problem. Besides, if the goal is to release broken software to inspire participation, how does the goal get changed back to releasing quality software? When does it happen? Who decides?
Good reputations are hard to come by, and it’s a shame when a project willingly damages theirs by misleading users or wasting users’ time by releasing software that isn’t ready.
As I said before, it would be good for KDE if its motto was, “The users come first.” That, or, “WE DO NOT BREAK USERSPACE!”
Im my opinion, for not speaking english, you have chosen almost the right words for describing the scenary, however please take account that not all of us (including you) fit in your description, maybe many (perhaps the majority) but not all are arrogants. I’m sure you know that applying universal quantification here doesn’t hold (but your feelings are very clear)
Also note that is very little you (or any) can do in order to change the personalities of those developers. However is clear KDE needs some strong voices that can set the lines on many aspects, because many users has expressed his concerns about nepomuk, akonady, activities, plasma, rewrite everything with the last shining technology -aka qml and stuff- and that developers doesn’t work in testing and fixing errors. Indeed, KDE needs to satisfy a correct rule like “The users come first.”
The only thing one can do (until/to we see some changes) is to do our work the best we can. A better path from here would be take your concerns to the list (kde-testing maybe) and build a working plan to correct the faults: KDE has all the infrastructure, it only needs mates that can push their actions and be consistent with his words.
Best regards,
Some kde dev/user/fan … in sum: someone that share your opinions.
Oh and please (to others devs) stop using tools like code of conduct, also stop doing threats about ban this blog from the planet. Is sad when someone has to read things like: Would you be OK to remove your blog from planetkde? … and I call it for what it is: a clear threatening.
@Adam: FWIW, I didn’t mean that as my end-all, be-all theory of FOSS development, what I’m saying is that there’s a certain pressure to ship somewhat regularly because (a) you need to keep up public awareness of your existence so people know there’s something they can contribute to and (b) people lose focus and momentum if the road from writing code to end-user delivery is too long. You can say “this should not be so!” all you want; meanwhile others have to actually contend with this just being the reality of how humans are and figure out how to make good software anyway (e.g. by taking a look at our process, tooling and overall efficiency to keep that road short without compromising quality). Do I think KDE can and should improve there? Of course! And yes, shifting mindsets and influencing the priorities people have in their heads is part of that.
Personally I believe that during the early KDE 4 days (before and for some time after 4.0) the community perceived this pressure to be very high, and hence made the decision to start releasing 4.x when it did. I’m thinking that given the different place we are in now, and given our plans for “KDE 5” (which are far more iterative than the 3->4 transition had to be), we have some breathing room now as a community to reflect and revisit some of these things. That’s a process I personally welcome.
But it has to be done in a positive way that doesn’t burn people out. You can’t deny that both the blog post and the comment thread featured a high degree of plain antagonism (it starts with the constant use of “they” already), which results in setting up You and Us camps, and is it any wonder what reaction you’re getting to that? If there’s no one left in the Us camp there’s no one left to make the software the QA of which the You camp is criticizing. People are protective of each other here because they know that, and they don’t have your luxury to ignore it. So I wish this blog post had been written differently (see my first comment) to avoid getting forced into Us vs. Them.
@tyner
Of course not all of them are arrogants! I know a lot of them which are just… good coders, nice guys and such. I met several at some Akademys long ago. Even Aaron was quite a nice guy, if you go by the rules of “KDE rules, eveything is so nice and us as a communauty are just OH SO F* GREAT”.
Concerning the planet, actually i’m suprised not to be banned yet. Even if i just politely say what I think, i expected to be banned in the name of “code of conduct” or whatever “politically correct” way of censoring.
@eike
You really are much into the us/they stuff, aren’t you ? As said, if i use “we” i got insulted by some kde dev. This and the fact that i dont like being linked with unpolite people, I’ll stay with ‘they’ until further notice.
And you know what ? I don’t have the motivation to work in such a hostile team. The need is for a change and KDE doesn’t even agree about the problem, this put the amount of work far far too high. Also, I prefer coding/designing than fighting. I’ll keep my available time to work on other projects.
Seeing that my mentioning the Code of Conduct in an earlier comment has been interpreted as a kind of threat, I thought I could clarify a bit what I mean.
I am not saying at all that it is wrong to point out things that went wrong in the past. But for me, the main message of the Code of Conduct is that if you do point out mistakes that happened, then you should do it in a way that is likely to improve the situation in the future. Say in a pragmatic way what happened, how you think it could be improved, offer your help with it.
I also think that someone with a KDE developer account who notices a problem before the release and thinks it’s serious enough to qualify as a release blocker should take action before the release. Sending a mail to the release team is easy enough. How can you complain after the release that nobody did anything if you didn’t do anything yourself?
Finally, I think that the sentence But hey, having a working systray is so much less fun than having a webpage embedded in a plasmoid, dude and the statement that KDE does not care about users are not quite in agreement with the Be respectful part of the Code of Conduct. There are many KDE contributors who work hard to fix serious bugs in the area they are working on as fast as possible.
Eike,
> there’s a certain pressure to ship somewhat regularly because (a) you need to keep up public awareness of your existence so people know there’s something they can contribute to and (b) people lose focus and momentum if the road from writing code to end-user delivery is too long. You can say “this should not be so!” all you want; meanwhile others have to actually contend with this just being the reality of how humans are and figure out how to make good software anyway
I think there’s certainly some truth in what you say, but I still think that quality can come first, or much closer to first, and things can still get done. Debian is an example here: the software is not released until it is ready, but they are still quite relevant and well-known. I’m not suggesting that KDE should take anywhere near as long as Debian does between releases, but the example remains. The testing/unstable/experimental infrastructure is also an example of an effective way to keep quality high while still providing access to software that’s current or nearly so. Users can choose how stable and how recent they want certain packages.
> But it has to be done in a positive way that doesn’t burn people out. You can’t deny that both the blog post and the comment thread featured a high degree of plain antagonism (it starts with the constant use of “they” already), which results in setting up You and Us camps, and is it any wonder what reaction you’re getting to that? If there’s no one left in the Us camp there’s no one left to make the software the QA of which the You camp is criticizing. People are protective of each other here because they know that, and they don’t have your luxury to ignore it. So I wish this blog post had been written differently (see my first comment) to avoid getting forced into Us vs. Them.
I understand what you’re saying, but I think you’re blowing this way out of proportion. Thomas has given a reasonable explanation of why he chose the terms he did. He also pointed out that he’s not very active as a KDE dev anymore, so that’s another reason to refer to the active KDE devs as “them.” It’s not intended to be divisive but simply a way of being honest about the relationship he currently has with KDE. I feel like some of the KDE folks are looking for every excuse to criticize and dismiss Thomas; that is disappointing.
> I understand what you’re saying, but I think you’re blowing this way out of proportion. Thomas has given a reasonable explanation of why he chose the terms he did. He also pointed out that he’s not very active as a KDE dev anymore, so that’s another reason to refer to the active KDE devs as “them.” It’s not intended to be divisive but simply a way of being honest about the relationship he currently has with KDE. I feel like some of the KDE folks are looking for every excuse to criticize and dismiss Thomas; that is disappointing.
Well, allow me to list some facts I notice :
1. Thomas has one developer account , but he is basically inactive now.
2. Thomas doesn’t use Plasma Workspace, but he still uses a few KDE applications.
3. Thomas writes a blog post to planetkde, with some bad communication skills like separating “them” and “we”, criticizing without constructive action/advice.
As one relatively new member of the KDE community (I became a KDE user in 2010 and got my account in the latter half of 2011), I’m really surprised and disappointed to see such an post on planetkde. Why, because I see planetkde as one important communication channel within the KDE community, for *both* developers and users. It is intended to make community members ( both develoers and users) understand and help each other , not to make them hate and fight each other. It is intended for people who see themselves as part of KDE community and would like to help, not for people who say “And guess what KDE did ?”, which sounds they are external to this community, without taking action to improve the situation.
Thomas, it is OK for you to see yourself not one KDE developer since you are inactive for long time. It is also OK for you post such a post to anywhere, except to planetkde. You are still using KDE applications and thus still part of the KDE community( the bigger one, not the smaller KDE developer community). So:
* If you really do not see yourself as part of the KDE community, please remove yourself from planetkde since that is for the KDE community. If you have forgotten how to do it, I’m willing to ask someone to do it for you.
* If you still see yourself as part of the KDE community, please write your post to planetkde with better communication skill next time. It is OK to criticize, but it should be written in a way that makes planetkde readers feeling the post is from someone who sees himself/herself as part of the KDE community and cares about this community. At least, it should read like “I think we have problem A…. Here is what I think need to do” instead of “Look! they have problem A….. See? I told you!”
To sum it up, if this post doesn’t go to planetkde and just goes to reddit/slashdot/phoronix, I wouldn’t spend the time in writing this long reply with one non-native language. I have enough emails from bugs.kde.org to read/check/reply.
@jekyll
What to say ? KDE dev really seem to focus on hate and the very importance of “us” versus “them”. It is so typical of how things have changed. 10 years ago KDE dev were focused on code and design.
90% of comments are about me or about minor facts compared to the problem i’m trying to speak about.
I’m fed up with comments like “bad communication skills”. Stop insulting me. Go instead read your “code of conduct” again and stop considering it as a tool to prevent people from criticizing and apply it to yourself. FOR ONCE. Or maybe it only applies to people outside your mighty communauty ? Honestly, seeing some people in the holly KDE communauty, i’m ashamed of being part of it.
Of course i do not consider myself as KDE dev. i haven’t did any commit for years and even there, those were minor. (not counting eigen which is not really part of KDE any more).
I’m also fed up with KDE dev asking about removing me from planet. What’s the deal ? You don’t dare banning me ? That’s your problem not mine. My post was about KDE and I think it has its place on planet KDE. If the “KDE communauty” is unable to sustain criticism, censor me and assume that you do but don’t hide behind “Oh, do you want us to do you a favor and remove you gracefully”. Take your responsability.
@thomas
> 90% of comments are about me or about minor facts compared to the problem i’m trying to speak about.
That “90%” fact at least would make me think about whether I have written something correct in a wrong way, if I were you.
And to tell the truth, I don’t disagree the (general) QA problems you have pointed out because I am aware of it.
As I have said, I wouldn’t add reply if this post is not sent to planetkde. I’m fine with your original post, because it has valid points as criticism, even if it doesn’t give/show any advice/action/willing to improve the situation. That kind of criticism is totally OK for someone who see himself/herself as external to this community. But for planetkde, I don’t think that kind of criticism is OK or good enough. If it is a criticism to be sent to planetkde, it should start with pointing out the problem and then give advice on how to improve/solve it .
I’m saying that because I actually have wanted to write some post about bugs.kde.org for quit some time . As someone who watches all mails of bugs.kde.org, I think I really notice some problems many others are not well aware of. And If I write it in the same way as your original post does(pointing out problems, blaming “them”, no advice nor help, just hahaha), I’m sure the result, no matter how many valid points I have made in my post, will be the same: people will be annoyed by the way I have written, not by what I have told them, then they will either ignore my post or fight with me, which in the end makes my post a total failure.
If the purpose of your original post is to making more people aware of the
problem and paying more attention to QA, then that “90%” fact proves your
original post turns out to be a failure. If I were you, I would have made
reflection on how it comes to a failure:
* because KDE community is full of hate and can’t bear with criticism.
* because I wrote it in a wrong way and sent it to the wrong place.
> 10 years ago KDE dev were focused on code and design.
Well, 10 years ago I even didn’t know about Linux, so I really can’t compare then with now. But I don’t see how focusing on code/design conflicts with good communication, let alone I don’t see how KDE now is not focused on code/design, based upon all the activities and mails I have noticed on bugs.kde.org and various development mailing lists.
And out of curiosity, since you say you have only minor involvement, how do you come with the conclusion “10 years ago KDE was focused on code/design” and “now it is focused on hate” ? I wouldn’t make such bold statement on something I’m not deeply involved, especially when it is related with such a long time frame.
> My post was about KDE
That is true.
> and I think it has its place on planet KDE
That is true only when the post is written in a constructive way and from someone who see himself/herself as part of the KDE community. If planetkde gets many posts which makes community members fight with each other, then it becomes a tool for de-communicating instead of communicating.
So, not every post about KDE should naturally go to planetkde.
> If the “KDE ommunauty” is unable to sustain criticism,
Did I say it you are not allow to write criticism ? I ask you to write your criticism with better communication skills, in a way that is constructive, makes readers pay attention to the contents instead of the way it is written, help solving/improving the situation. Does you original post provide any such benefit?
> censor me and assume that you do but don’t hide behind
I didn’t hide. I ask you opinion and confirmation about whether you still see yourself as part of KDE community right here in public before I take action. That is called as due respect.
And it seems you are in the wrong mood . You seems to take everyone criticizing how this post is written as hater. I don’t like nor hate you, because I basically know nothing about your previous activities related with KDE. I add my reply/advice in the hope that if you still see yourself as part of this community, you can do it better next time you post something to planetkde and get better results than this post did.
Finally, repeat, the only reason I add my reply is this post was sent to planetkde.
Jekyll,
I wish you would hear yourself from others’ perspective. I am dismayed by your words to Thomas. You continue to parrot, “You have bad communication skills,” “How about I remove you from planet?” “You didn’t say it right,” “You said it _wrong_,” “It’s not ok to say it that way _here_,” “If 90% of people complain about what you said, that proves you said it wrong.”
All you’re doing is asserting your opinions as fact. You’re not proving anything. What you’re trying to do is control other people. You’re trying to conform a community to your personal vision of how it ought to be.
Guess what? Thomas can’t control how others react to his words. You might think he should have phrased it differently, but here’s some news for you: no matter how nicely you say something, if you’re criticizing someone or something, someone will feel offended.
So what? There are people who are constantly looking for a reason to feel offended. Personally, I am offended by people who are offended all the time.
An early sign of decline is when a society becomes obsessed with rules of political correctness or politeness. Too much emphasis on form over function results in bureaucracy.
And you know what else it does? IT DESTROYS PASSION. If people care strongly about something, they are going to express themselves with vigor. That doesn’t mean with rudeness, but it may very well mean using sarcasm, exaggeration, expressing frustration, etc. If people aren’t allowed to express their convictions, a part of them dies inside. And there’s no quicker way to oppress people and DISCOURAGE PARTICIPATION than by forbidding them to express themselves. Requiring people to act like robot butlers means you will only have people participating who have little passion for the project. Now that’s a recipe for irrelevance.
I can’t help but think that part of the reason Linux is so successful is because there are passionate people involved in leading the project. Sure, they rub people the wrong way sometimes, and they butt heads now and then, but that’s because they CARE. If they didn’t have passion, it would be like a corporate project run by a hierarchy of managers trying to squeeze enthusiasm from overworked cubicle dwellers–you know, Microsoft or something. And then it would be garbage that only giant, bureaucratic, narcissistic corporations would use.
I really don’t want KDE to become like that.
The choice is not between hateful-and-mean or never-offending-anyone. The choice is between allowing people to be passionate or suffocating them. If KDE isn’t careful, it’s going to push away the people who care the most. Step 1 was foisting KDE 4.0 on people before it was ready. Step 2 may be forbidding enthusiasm that doesn’t jive with the groupthink.
The bottom line is this: people in KDE should stop criticizing Thomas for how he said something. Instead, they should say to themselves, “Wow, this guy has a lot of enthusiasm for KDE! He really cares! He is passionate about KDE improving! We need to get this guy more involved in KDE! He has energy that can be put to work!”
Instead, he’s being pushed away, and his passion is being stifled. His enthusiasm isn’t welcome because he doesn’t agree with everyone else about everything. He’s “saying it wrong” because he’s willing to call it like he sees it, without pulling any punches or watering it down.
Maybe KDE is getting too big for its own good.
@jekyll 20:58
I’ll just respond to two points.
“give advice on how to improve/solve it”. Actually I did, I’ve thought about it a lot more than what you think. If there was an obvious solution like spending a lot of time testing/triagin, i would even probably worked on it. What I’m trying to say is that i think the problem is a lot deeper. KDE is i NO need of more dev or better devs. There are already a lot of good coders there. I think the problem is about the attitude. And the only way to “fix” this kind of problem is not by patching, is not by adding tools/administrativia. It’s about communication. What i try to do. I try to say politely and quietly what i think is wrong. I was ready to be insulted by some of them (often the most verbose people, and often by childish newcomers or even some who aren’t even developers). This is fine with me. I care about KDE and the uber-coders there. Honestly I have never heard about you, I don’t know what your participation is, if ever. So I don’t really care much about what you say. A little bit, but no more.
With respect to planetkde, you might notice that only the category “KDE” of my blog is aggregated on planet. This, and I will never post any non-technical stuff. I think carefully about what I post there. This might have not appear to you, but it’s not what others do. Most people on planetkde are not as careful (check urls on planetkde “people aggregated” tab upthere). Back then when I was much more in the “KDE communauty”, the signal/noise ratio was just awful, with most entries about personal life, funny stories and cats. Ugly. And you came here telling me how my communication skills are bad ? *sight*. I just hope it got better now.
> Honestly I have never heard about you, I don’t know what your participation is, if ever. So I don’t really care much about what you say.
Jekyll is Konsole’s maintainer, and has done a ton of work to make that and others higher-quality applications over the last 12 to 18 months. You should care about what he has to say.
Come on, Thomas, reading your post again, the reaction was clearly expectable.
That said, I consider anyway your post to be very useful and to go further, I would also think that the KDE community would gain a lot by winning you back as an active KDE developer. So while most people disagree with your communication method, it should not be the focus on the discussion.
To be honnest, the problem you point out is probably valid but is not really the reason for your post. It was just the catalyst. The frustration, which is actually shared with others, has several sources:
– temporary degradation of the overall stability (nepomuk, plasma). BUT: there has been some huge progress in the latest months
– new communication methods: the emergence of blogs tends to give the priority to marketing and nice words instead of focusing on the software quality (which explains your conclusion that KDE is no longer driven by nice code but by politics). As a results, KDE has been exageratly over-personified
– many decisions have been defended to death by a few KDE “speakers”, instead of being challenged. Probably because of the over-personification of KDE, many choices were definitly a personal thing and any critism was seen as a personal attack.
I personally don’t think that the KDE people have changed (except for a few new “stars”…). It is wether “we”, nor “they”, the actual thing is that some decisions must be made (new technologies, new UI, QA processes) and not by individuals but in a way that is beneficial for all. In my opinion, there are 2 major processes missing:
1. Make the KDE community as a whole (not only 1 or 2 developers/speakers) aware of specific problems (major bugs, technology issues and usability). A kind of official way to raise an alarm…
2. Make sure that a discussion is possible and only close it after a real consensus or at least a clear agreement from the majority
In that case, pointing to critical issues would be done in a very efficient way, helping the community to have the right approach instead of generating conflicts.
To give a bit of an outside view as well (KDE user, supporter via join the game, not a dev):
The raised points are, in my opinion, valid. I had a few very interesting discussions with a few KDE developers after this post, which I probably would not have had without it. However, what matters is whether things are actually going to change and the QA/Release process will be improved, else we will probably have more such posts in the future. Reading the release team mailing list as an “outsider” is not really motivating either. There have been a few suggestions on the mailing list from several sides, but most of them are just turned down right away.
A few people recommended making people aware of critical problems. But what are critical problems, who decides that and _how_ to make people aware of it? As a user I see the bug tracker as my main tool to make people aware of issues. And there have been a few issues that I either filed a bug for or commented on existing bugs. A few of them that are, in my opinion, rather critical made it into the release anyway, and having a quick glimpse at quickgit suggests that they haven’t been fixed yet, so they might very well make it into 4.10.1 as well. A typical example would be the currently not really usable notifications (text is cut off, buttons are cut off and not readable at all …). If users end up deciding what is critical and forward such bugs to places that seem to be more appropriate, such as mailing lists, or put them in a blocker status, probably the current mess at the bugtracker, which is not really manageable for a few products/projects anymore with the manpower given, would just move over to whatever place you prefer.
Also from an outside perspective the discussion here is not really held on a level which gives a good impression, and this goes for both “sides” involved. Neither repeatedly trying to get this blog out of planet kde, which I as a user would indeed see as unneeded censorship and not being able to handle criticism, nor the pointing fingers, calling names and using rather lurid headlines seem like a sane, pragmatic and solution oriented discussion to me.
I understand that developers, QA people, testers and others who do really hard work don’t feel nice or motivated when they have to read such posts. And a few developers, as an example Vishesh Handa, were really nice and working together with me to get bugs fixed, which unfortunately still made it into the release (tags kio not working with umlauts, spaces and other characters). So it feels a bit bad to write criticism, because I know that there are people who work really hard and care a lot. But in the end shipping a product with bugs will hurt the reputation of KDE and the acceptance it on “our” user side. So posts like this should be a warning siren that some processes have to be improved or redesigned.
Christian (Fuchs in most places)
@christian
Just as a quick follow-up, I of course don’t consider all KDE dev bad (either code-wise or from a human POV). Saying so would really be stupid, and I’m glad i never did, this is just what some frustrated dev are trying to spread about me because they can’t stand criticism. It’s so easy to misinterpret stuff.