Hi Michael, On Monday, 2013-10-28, 12:22:15, Michael wrote: > Hi Kevin, > > Am Sun, 27 Oct 2013 13:08:10 +0100 > schrieb Kevin Krammer <kram...@kde.org>: > > On Sunday, 2013-10-27, 07:54:09, Michael wrote: > > > Granted, not all issues will face on every system, something > > > triggers the issues, sure. Not all users will think some stuff is > > > implemented weird and in a rather un-usable state (even if I think > > > something must be wrong with them then, as I can even understand > > > the Gnome-decisions and way of implementing things!), not everyone > > > has the same need and idea for a feature and how to implement it. > > > Some may never have any issue whatsoever, be it just coincidence or > > > they just don't use that particular feature or at least not in a > > > way that the issues would show itself. > > > > I guess this is at the heart of the problem, i.e. issues or weird > > behavior only triggered under certain circumstances. > > Computer systems have a huge variety of aspects, each potentially > > contributing to the observed behavior. > > And I guess that is not the point, at least it is not the primary > point. Especially to negate such arguments I did provide some links to > show that the issues are NOT limited to corner-cases or weird and > unusual user setups.
I didn't claim it was the full problem, just that large number of influences is at the heart of the problem. During analysis it is often estonishing how many different code paths can be executed depending on factors one wouldn't have considered at all. Especially since an observed behavior is often just a symptom. Fixing the symptom is nice short term but finding the cause is the real deal. > > It often takes a concerted effort of many people to narrow down those > > candidates to the actually contributing factors in order to make a > > problem reproducable with enough reliability to analyse and fix it > > (including verification of the solution). > > Even though that might be the case for some cases, it can't be for the > vast majority of issues, as I could easily reproduce most issues > reliable on different boxes. Good :) I wasn't saying that all things are hard to reproduce, just that often narrowing down the variables to just the contributing factors can be time consuming. > And yes, sometimes issues are really hard to track down. I myself know > that for a fact. But I do know that many issues are visible in the code > quite clearly too. Those are usually easy to fix then and make good candidates for contribution entries. In KDE's issue system they sometimes get labelled as JJ (Junior Job) to indicate that they are considered suitable tasks for people who have not dived into the code base that deep yet. Sometimes those turn out to be just a short term measure which hides the actual problem though. Still a good start. > There may be issues in one part of the stack that > only affects some applications under some circumstances but it is not > clear where in the stack the actual bug is. But for many other issues, > it is quite clear where the issue lies, or at least where it most > likely lies. Over the years I did report an abundance of different > issues, be it kernel or userspace related. I'd say 90% of them were > rather easy to track down. With some help from a friend who knows > *some* C we were able to track down one bug without having any clue > about the code itself. And it was an issue that was open for years and > it clearly showed the lack (for whatever reasons) of interest upstream > had in that issue. How did you determine that it was a lack of interest and not a lack of something else, e.g. resources? Somebody commenting that they don't care? > > > So, that all said, what do you guys, users and maybe even > > > developers of KDE, think? I don't want to come around as rude or > > > overly harsh, as really, I think KDE is a great Desktop > > > Environment, it just has some really rough edges. Is it just me, or > > > are others also thinking KDE could / should invest more efforts in > > > QA and maybe less in implementing new stuff? I know, "send patch" > > > yada yada... that does not apply here, at least not well enough. > > > > It does apply here as well. While sending a patch is a particular > > form of contribution, e.g. providing a potential fix, it is generally > > a suggestion to get involved [1] in the process of finding a solution. > > No it does not apply WELL! It does apply to a certain and rather > limited degree, but hell no, not on an average scale. Why not? Suggesting involvment is a nice way to emphasis that the project and/or community is open, that the reporter is not assumed to be clueless or incapable just because there has been no prior contact, etc. You would be surprised how often people assume that something is out of their hands or that their potential work would not be considered of good enough quality. I've seen people enthusiastically rework whole wikis once they found out that they were allowed to just go ahead at their own discression. > I know and > absolutely agree that KDE and GNU/Linux in general is > contribution-driven to some degree, but that is it exactly: to some > degree! Most projects want their users to just report bugs and if > something is not clear help them to reproduce a bug and maybe even > track it down with some trial and error approach. Almost no project I > know of thinks (or expects) that most if not all users can actually > code, know any computer language or are able to fix the issues on their > own. Right. Not even expected from most contributors. In most projects it is only the software developers who code, but I've seen translators and documentation writers fix user interface issues that went beyond changing string contents. But I don't know any community where it would be assumed that the non-coders would be able to do it on their own at all times. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.