Bug 329793

The crash happens deep in the Qt library. I suggest to update Qt to version 4.8.5. While you are using newest KDE 4.12, you are still using a quite old Qt 4.8.2.

Please provide details as to how to update Qt in ubuntu 12.04.3  I run apt-get update daily and install all updates.  I don't know why it wouldn't have come down if it was there...

Thank you

Please ask in Ubuntu forums how to update to Qt 4.8.5.

I'm told to compile the source.  Quite strange to me that I should need to go through these gyrations. Working on compiling it now.

Basic XLib functionality test failed!
 You might need to modify the include and library search paths by editing
 QMAKE_INCDIR_X11 and QMAKE_LIBDIR_X11 in /usr/local/src/qt-everywhere-opensource-src-4.8.5/mkspecs/linux-g++.

This is where I get off the boat.   For a user to have to be a developer to use a simple IRC client is ridiculous.  Bug is NOT resolved.

Here are the facts we know:

- The crash information in your bug report tells us the crash occurs inside the Qt library used by Konversation.

- Your version of the Qt library is almost two years old.

- There are many Konversation users, but you're the only one reporting this crash.

This leads us to conclude that the bug is unlikely to be in Konversation, and unlikely to be something Konversation can affect.

It also seems likely the bug would go away for you if you used newer software, since otherwise we'd be seeing more crash reports like this.

For any Konversation developer to be able to do anything about this bug, we'd have to be able to reproduce it, but we can't reproduce it with the available information, nor do we have such old Qt versions ourselves to test with.

Hence there's nothing we can do, and while I understand you're frustrated the app is crashing for you, there's no immediate use for this ticket to stay open.

What I object to is the message you're sending.  The problem has not been resolved in any sense of the word.  "Deflected" would be closer to the truth.  "Won't fix" is also reasonable nomenclature for this situation.  "Resolved" implies fixed.  While that may be what you consider it as far as the application code proper is concerned, it is not an accurate reflection of the status of the problem from my point of view.

There are facts, and then there is customer service.  If you wouldn't say it to your grandmother, then you shouldn't say it to anyone else, especially not a customer.  And yes, anyone using the software is a customer aka user.

The fact that nobody else is willing to go out of their way to take the time and energy I put forth, along with the knowledge required to make it all the way to this point speaks not to the solidity of the software, but of the tenaciousness of the user.  I spent over 8 hours today alone chasing this down trying to get it resolved.  The vast majority of users - especially those of a non-technical background - wouldn't put up with, nor spend their time on this kind of nonsense.  First the application would get dumped for something else, and failing satisfaction with that - then abandonment for a different OS entirely where the support system doesn't force the user to be a tech guru.

I've been using Linux for years and I've been as big an evangelist as anyone.  But quite frankly I'm embarrassed to recommend it to anyone without a strong technical background because of exactly this kind of issue and associated attitude.

I do appreciate that the problem is not strictly within the konversation code proper, but instead within a component used by konversation, but that doesn't mean there's nothing you can do.  To say "nor do we have such old Qt versions ourselves to test with" is patently false, because I didn't go out of my way to downgrade to this version.  This is what came with the system and is readily available to anyone that wants it as I installed it fresh not one month ago - the one labeled "LTS" - Long Term Support as you well know.  Do I expect you to go out of your way to test with an older version when something newer and more exciting is available?  No, not really and I can appreciate that there is a newer library component which may or may not fix the issue.

While upgrading to newer software (where "software" could mean a wide variety of things from just the library to the entire OS) might be the proper solution from your point of view - and I'm not necessarily objecting to that as the solution (upgrading the library, not the OS), what I do object to is the general "it's not my problem you're on your own" attitude.  Which leads me back to - is that what you'd tell your grandmother?

The proper way to have handled this would have been to take ownership of the problem - whether it's truly your area of responsibility or not - and guide me as far as you're able.  That means this response "The crash happens deep in the Qt library. I suggest to update Qt to version 4.8.5. While you are using newest KDE 4.12, you are still using a quite old Qt 4.8.2." was a very good start and I applaud Cristoph for it, but could have gone one small step further with "Do you need help with how to do that?" and then a bit of handholding through the process; even if you didn't know how and it meant figuring it out yourself.  Instead that was the end of it as far as your team were concerned.  As the process failed (locating a pre-built library as well as compiling one), I should have then been helped with reporting the issue to the proper place; personally "walked" to the next link in the chain so that I didn't feel abandoned.

Finding that place - and procedure -took me all day today, when with a bit of help from someone knowledgeable like yourselves, that time could have very well been reduced to minutes.  And that's the real issue here - the "we really don't care because it works for us so go figure it out for yourself" mentality.

No response is expected, just do better next time.  For granny's sake.  It's just the right way to treat people.  Do unto others as you would have them do unto you.

Thanks

> There are facts, and then there is customer service.

This website is not a customer service venue, it's a developer tool. The goal is to do well by our users, but to do so we have to operate with efficiency, and keeping the bug database in a condition useful to developers helps with that.

Yes, we could kiss your arse and hand you chocolates and all the other trappings of traditional customer relations, but the relation we prefer is to treat you as our equal in the participative endeavour that open source development is (the fruits of which you also got for free, by the way). As our equal we hope you would mind the same broader concerns we need to mind, such as spending our resources wisely. With that in mind I did not deflect anything, instead I offered reason. I'm sorry you felt not respected, but I hope you can see the respect that is in transparency of that kind.


> To say "nor do we have such old Qt versions ourselves to test with" is patently false, because I didn't go out of my way to downgrade to this version.

None of the Konversation developers uses Kubuntu/Ubuntu. Konversation nor KDE are affiliated with that distro. "LTS" is a promise made by your system vendor; you should inquire why they don't support you by supplying bugfixes that already exist.

> "Resolved" implies fixed.

"Resolved" means, there is no further work to be done by KDE developers in this bug tracker.

This is either because the bug is fixed by KDE developers, or has to be fixed elsewhere. If you want your distribution to supply newer Qt versions, please report this to the bug tracker of your distribution.

(In reply to comment #8)
> you should inquire why they don't support you by supplying bugfixes
> that already exist.

Where's the bugfix?

> Where's the bugfix?

I was referring to the dozens (if not hundreds) of bug fixes listed in the Qt 4.8.3 - 4.8.5 maintenance release changelogs.

The reason in that case is: Last someone (not me) checked, KDE did not claim to support Qt versions released after the release of a given KDE SC version (in fact I seem to recall an incident where mixing  a newer Qt maintenance release with an older plasma-desktop release actually went south). Or more generally put, because changing the entire version of a toolkit library has too great potential to go wrong only selective fix backporting is done. So, since Kubuntu 12.04 contains KDE SC 4.8 it uses Qt 4.8.1.

On that note, the report is definitely not from an actually supported Kubuntu 12.04 because it indicates Qt 4.8.2... handling this in the new downstream report though.

Thanks Harald.

(In reply to comment #8)
> > There are facts, and then there is customer service.
> 
> This website is not a customer service venue, it's a developer tool. The

Really.  So then you're NOT interested in bug reports from users.  Good to know.

> goal is to do well by our users, but to do so we have to operate with
> efficiency, and keeping the bug database in a condition useful to developers
> helps with that.

And how are my previous suggestions at odds with "keeping the bug database in a condition useful to developers"?  While "resolved" may satisfy your needs, there's no reason an additional flag couldn't be added.  Something like "Dependency Broken" perhaps.  I'm sure you can think of something appropriate that would satisfy everyone's needs.

> Yes, we could kiss your arse and hand you chocolates and all the other
> trappings of traditional customer relations, but the relation we prefer is
> to treat you as our equal in the participative endeavour that open source

I don't need kisses or candy, but it's a symbiotic relationship.  I'm not a Konversation developer, I'm a Konversation user.   Without users there is little reason to have the product.  That means we have an equal interest, it does not necessarily mean we have equal skills or knowledge.  The developers are intimate with the product and it's components, the users are not - nor should that be a requirement of usage.  You are strongly implying I should have the same skills & knowledge as a developer of your product, if I want to use your product.  If that's true, then this isn't the right product for me as I want to use the product, not troubleshoot it.


> [...] Kubuntu/Ubuntu. Konversation nor
> KDE are affiliated with that distro. 

Well that I find to be a fascinating statement, which puts an interesting perspective on the situation.  It means K/ubuntu bares responsibility for making KDE and Konversation work on Ubuntu, which I suppose makes sense.  But it does require the user to be knowledgeable about the situation.  The average user doesn't care who is responsible, s/he simply wants to have a working system.  If the system doesn't work, the user generally goes elsewhere if at all possible.  Users tend to gravitate towards the path of least pain.

"LTS" is a promise made by your system
> vendor; you should inquire why they don't support you by supplying bugfixes
> that already exist.

And you are absolutely right that bugfixes should be supplied by the vendor.  Unfortunately the problem is one of complexity.  Once again, you are requiring the user to be intimately familiar with a highly complex system that is comprised of an overwhelming number of similarly complex pieces.  The user cannot be expected to understand the details of the relationship between subsystems, and so it falls to the developer to notify and interact with the system vendor, else it is likely that the problem will not get fixed.

Here's what will typically happen instead 
Newbie: "So I'm looking for an IRC client for Kubuntu.  Any recommendations?"  
Voice of Experience: "Yes.  Whatever you do, avoid Konversation because it keeps crashing and the developer doesn't care."  

I would hope that's not the result you want to see, and I don't think you understand that is in fact the result that you'll start getting if it happens too often.  When someone takes the time and trouble to report a bug - and I can promise you that it is a HUGE HASSLE to report bugs - it should be handled with all the importance of your product's reputation in the marketplace - free or not.   

Now if you don't care, I certainly can't force you to care.  If you have a different opinion, you are entitled to it just as I'm entitled to mine.  I've taken the time to share my thoughts with you in the hope to convince you - and others watching - that I think there's a better and more proper way to do things.  As you well know, I can't force you to do anything you don't want to do.

I moved from Quassel to Konversation recently because I didn't like the way that product handled certain features.  I put up with it because I didn't know there was another choice.  I was able to make the move because someone on an IRC channel made an offhand comment about Konversation while talking to someone else.  I didn't even know about Konversation's existence before that.  And that's how most products survive, thrive or die - by referral or the lack thereof.  I like Konversation, but if I can't use it then what's the point?

I made the effort to help keep your product alive on Kubuntu, by finding the proper place to report the problem, so this particular incident is moot.  However next time I just may not bother.  I can only hope my words are heard and taken to heart by any of the unknown number of people reading this.  Thanks for listening.

> While "resolved" may satisfy your needs, there's no reason an additional flag couldn't be added.

There is an additional flag, the bug status is "resolved UPSTREAM", which means the bug is in a component not in control of KDE developers, this time the Qt library developed by the Qt project. Before going to point you to the bug tracker of the Qt project, I wanted to make sure the bug is still reproducible with Qt 4.8.5.

For more information, please read http://www.kde.org/code-of-conduct/

(In reply to comment #9)
If you want your distribution to supply newer Qt versions,
> please report this to the bug tracker of your distribution.

This gets to the heart of the problem.  You should be the one to take responsibility for reporting it.  It took me an entire day and part of my night to figure out 1) that I needed to report it, 2) where and how to report it.  With an additional 5 minutes of your time you would have saved me 10 hours of mine.

Eike stated "As our equal we hope you would mind the same broader concerns we need to mind, such as spending our resources wisely."

Yet here we have an example where this is blatantly not true.  I'm not being treated as an equal, because you've decided that 5 minutes of your time is more valuable than 10 hours of my time.  You saved 5 minutes of your time and squandered 10 hours of mine.  How is that equal?  Or fair?

> So then you're NOT interested in bug reports from users.

On the contrary, I'm very interested in bug reports from users. But bug reports are contributions to a participative development process, not a customer service inquiry. You're informing us you've noticed what may be a bug; we're going to use this information as we see fit to make our software better.


> While "resolved" may satisfy your needs, there's no reason an additional flag couldn't be added. Something like "Dependency Broken" perhaps.

That's exactly what "RESOLVED UPSTREAM" means. As a developer I agree that Bugzilla could be improved for our needs, by the way, and by extension the needs of our users, but this ticket isn't the place to discuss Bugzilla improvements.


> You are strongly implying I should have the same skills & knowledge as a developer of your product, if I want to use your product. 

No, I think you misread that. I don't think you should need to have the same skills and knowledge as I do (in fact Konversation stands to benefit more if you bring different skills and knowledge to the table). I do expect you to be aware of the mode in which Konversation is developed (by volunteers, non-commercially, in the open) and have more than your own needs on your agenda, e.g. the need for us to triage reports and decide where to spend finite resources to help the most users. If you can't do that, I recommend switching to a product that offers a different kind of relation with you indeed.

I've spent 8 years and hundreds of hours on improvements to Konversation, most of them due to suggestions or inquiries by users. Some of my fellow developers have been around even longer. I have a very clean conscience about my contributions to the bottom line here.


> The average user doesn't care who is responsible, s/he simply wants to have a working system. 

That might accurately reflect the status-quo, but isn't a desirable state of things, partly because it's not sustainable. We don't have the resources to hide the complexity of the development process from users or succeed without your help. If we did, we'd also fail to recruit new developers to replace those who move on. We also feel that doing so does users a disservice in the long run, since you don't have the full picture to make useful decisions.


> The user cannot be expected to understand the details of the relationship between subsystems, and so it falls to the developer to notify and interact with the system vendor, else it is likely that the problem will not get fixed.

This is true, and you'll be relieved to hear that this communication happens all the time. The Konversation team (as well as many other people in KDE) maintain strong relations with many distros, and many bugfixes that distros end up pushing to users also in lower-level components are the result of us asking them to ship them. We talk literally every day, and improving this communication (e.g. by linking bug trackers to maintain upstream/downstream references for the same problem) is an active topic of conversation.

However, in this case it's not reasonable from a resource POV to do this until the bug has been confirmed to exist with a more recent version of Qt. The vast majority of our users use a newer Qt and we're not seeing the same crash report from them. Nothing in this report allows me to reproduce the crash with the software I have. I could spend hours setting up a system with Qt 4.8.2 and try to reproduce it there only to find out that it's been fixed in Qt 4.8.3, or I can't reproduce it at all and we're none the wiser.

These are the kinds of decisions I need to make all the time when deciding where to spend a finite amount of time to address the needs and concerns of many users. I'm not saying you should have been born with an awareness of that, I'm just trying to explain the background to the reaction you felt was offensive to you, and hope you can understand it better.


> "Whatever you do, avoid Konversation because it keeps crashing and the developer doesn't care."

I know this to be false; I care greatly.


> I would hope that's not the result you want to see

You might also be interested to learn that guilting people and blackmailing them with threats tends to have the opposite effect of what you think it has, especially with volunteer-driven development. Instead of being spurned by their honor to help you, people instead become depressed and burn out. In fact, protecting fellow developers from people who maintain their human relationships in this fashion is a particular concern of mine.

> Yet here we have an example where this is blatantly not true. I'm not being treated as an equal, because you've decided that 5 minutes of your time is more valuable than 10 hours of my time. You saved 5 minutes of your time and squandered 10 hours of mine. How is that equal? Or fair?

This is simply not an accurate reflection of how it went down -- Christoph did refer you to the next proper venue to inquire about the availability of a newer version of Qt for your system to test with: Ubuntu forums. The people there are more effective at helping with Ubuntu-specific problems than we are, i.e. you're likely overestimating our knowledge there. For example, I have honestly no idea if there is a newer Qt available for your Ubuntu version anywhere. I'd have to ask someone else or ask a search engine, too.

Christoph in particular triages tons and tons and tons of user reports almost every day, and it's not reasonable to expect him to write long step-by-step tutorials in every response that take into account all the variables you might encounter and that he would need to research himself. His time is better spent doing exactly what he did here, and exactly what you request: He used the knowledge and time he does have available to interpret and classify your problem, and tell you where to go with it. There's no reason to assume he wasn't acting in good faith and to the best of what his circumstances would allow.

I'm sorry for the mail spam, everyone, but an attempt to summarize this before I close out the day, in the hopes we can all move on: Your point that developers should have empathy for their users is well taken. I do understand the frustration you experienced, and I regret that this became somewhat adversarial. I'm also genuinely grateful that you did take the time and effort to report a bug at all, as said earlier I consider that a contribution to Konversation, and all contributions deserve respect.

Your contribution isn't moot, either. The problem on your end isn't resolved immediately, but you know now how it fits into the larger picture (-> no similar crash reports, so updating software looks like a good bet), and we won't forget either. If we get a similar report again, we have more to go on, and more to tell.

However, empathy has to go both ways; it's important for users to have empathy for the situation of developers, too, in particular with this mode of software development. Customer service is an ill-suited concept here since we are not, in fact, servants. Both kinds of empathy have to exist to grease the wheels of this process.