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

Mon Oct 28 14:12:41 GMT 2013

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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20131028/2234547e/attachment.sig>
-------------- next 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.