KDE's rough edges... what are your experiences?

[Michael]

Am Mon, 28 Oct 2013 15:12:41 +0100
schrieb Kevin Krammer <krammer at kde.org>:

> 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 <krammer at 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.

I feel without checking each ones claims how serious each and
every issue KDE has is or how complex a bug-hunt would be, we can argue
all day long how likely it is that any given issue is rather complex to
track down. I can only speak for those issues that I found, reported
and "helped" to track down with other projects (Xfce, Gnome, Mate, Linux
Kernel, mdadm, mesa / radeon, smuxi (<3) ...) and on average it was not
*that* hard to track the issue down. How complex a fix was... well, no
real idea as I can't code / don't know C or any other programming
language, but most of the time it was a thing of minutes a fix was
there, or at least the discussion on how to actually fix the given
issue started when the fix was not so obvious or easy to get right. At
least after all those years I tend to just think, the person who did
program the code, knows his / her way around to find an issue many
times rather fast. If KDE does differ there, no idea, but if so, why? I
would tend to think something must be awfully wrong then.


> During analysis it is often estonishing how many different code paths
> can be executed depending on factors one wouldn't have considered at
> all.

Well, let's stop right here the argument how complex any given issue
might get, just try to answer why KDE has compared to other DEs more
issues, if you even agree there. If not, why do you think many users
(me included) have such a "bad" opinion about KDE in that regard?


> 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.

Agreed, but see above.


> > > 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.

Well, life is no pony ranch, right? ;-)


> > 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.

But I hope you do not expect any given user needs to learn C / QT to
actually fix even those easy bugs. A question I did ask already here
and as you seem to be a KDE-developer (why else would you have such a
fancy e-mail-address?)... please describe the expectations the KDE
project / developers have for their users. And...

1.) Do you agree that KDE is more "buggy" than other Desktop
Environments?
2.) If yes, why do you think KDE has so many issues?
    If no, how come many users have such a bad opinion about KDE?
3.) How could the situation change? For better not worse. :)


> > 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?

"for whatever reason" did include possible time constraints and overall
lack of resources. If a developer does not have enough time to address
an issue, that means he prioritizes other issues higher. Which is fine,
but that would be the reason behind the lack of interest. "Lack of
interest" does not mean "I would have enough time and resources but I
just don't care enough", it is rather "I don't care enough to change my
priorities" (again, which is absolutely fine, he may even have
extremely good reasons to show "lack of interest"). I admit it is easy
to misunderstand, but such situations tend to get very complex if you
even try to understand each and every reason why someone did not fix a
given bug. And I really don't plan on thinking about every *single*
reason why each and every possible KDE bug was not fixed yet. Right now
I am just interested in the overall (KDE-specific?) situation, to see if
it would be possible to change something (best case, no expectations so
far though) or understand the issue (would be nice), but at least get
some (more or less) definitive answers about the whole situation, as I
really have a hard time understanding the big QA-difference.

> > > > 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.

"Send patch" does not sound like a nice suggestion, it sounds rather
like a demand. Which may be justified here and there, but it can't be
the general rule! But sure, a lot can be done when someone spends some
time phrasing such "demand". It might even sound like the best thing
that could happen to the reporter! ;) Or, it might even be that some
developers really mean this "demand" as a nice suggestion... but
in my personal experience it is rather meant as a demand, plain and
simple. But to be fair, to a good amount if times this kind of demand
is pronounced as a reaction to some rather harsh demanding attitude of
a user / possible bug or issue reporter: "I have this issue, fix it,
goddamnit!"
Bottom line, we should not demand anything from anyone here (that goes
both ways), we should suggest and ask nicely, try to tolerate and
understand each other...

	... and pursuit everlasting happiness! \o/ ;-)



> 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 would not, believe me. ;)


> 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 thought we talk about fixing code issues and not some other
arbitrary contributions?


> > 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.

Folks that could not program did fix code-bugs? O_o Sounds like a myth.
I tried it several times, but I couldn't make heads or tails out of it.
Or is QT *that* simple to read and understand? I only know how C, #,
perl, python and basic *g* looks like, no idea about QT.


> 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.

I'd say something like that would be impossible and idiotic to expect
without learning the language needed.

optimistic regards
Michael
___________________________________________________
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.