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

[Kevin Krammer]

On Monday, 2013-10-28, 17:56:50, Michael wrote:

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

Right. I was mostly addressing the difficulty to find the actual cause and 
fixing it properly that often increases the overall time required to 
completely resolve an issue.

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

I don't know. I have basically no issues at all with the DE. I do run into 
issues with applications now and then, but the DE works for me in all 
situations.

I don't have a multi monitor setup, though I often have to connect a 
projector. However the projector is never used as a "second monitor" in the 
sense of having a separate panel or something.

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

Obviously not. Why would you think I would?

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

I am but a @kde.org address is available to all long term contributors, not 
just developers.

> ... please describe the expectations the KDE
> project / developers have for their users. And...

I don't know. Since this discussion is about the DE aspect or KDE's DE product 
I can't say because I am not involved there.

> 1.) Do you agree that KDE is more "buggy" than other Desktop
> Environments?

Do you have any numbers? Are there more bug reports in a year files against 
Plasma Desktop than, say, GNOME Shell?

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

I can't be sure, but a guess is that the Qt technologies used my Plasma 
Desktop had not been as good as the DE developers had assumed and/or applied 
it in a way that wasn't considered.

Or maybe they attempted too early to create a flexible package and had to work 
around limitations that they encountered but hadn't planned for.

Not sure about bad opinions. most of the initial uproar about the Plasma seems 
to have settled down and I think the desktop (also often referred to as 
workspace) team has made great improvements over time. 

> 3.) How could the situation change? For better not worse. :)

I would say that a lot of knowledge has been acquired over the last couple of 
years, i.e. on how to build flexible workspace shells, pitfalls, etc.

As I said before I don't have any internal insights into the team's work but 
their communicated plans sound good as far as I can tell.

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

Well, lack of interest is a very different thing than lack of resources and/or 
time. The "for whatever reason" was applied to "lack of interest".

> If a developer does not have enough time to address
> an issue, that means he prioritizes other issues higher.

Not necessarily. That would only be a valid conclusion if the assumption that 
the time is spent on other issues would hold.
Resources such as time could be, and often are, drained by aspects outside the 
KDE contributing.

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

Well, as I explained above, that only applies if the other thing is a 
different contribution to the project or some other project.
However, most resource shortage is caused by other things.

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

Not really sure about the DE, but I think the applications have gained a lot 
by dedicated bug triagers. I guess that could be improved fruther by more 
people doing that and getting people into that who can already provide closer 
analysis.

Again not sure if this applies to the DE the same way, applications usually do 
not depend so much on system features/behavior and can be easily tested stand-
alone.

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

True, I was thinking in more generic terms. Obviously depends a lot on the 
phrasing.

> 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! ;)

Ideally, yes :)

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

Hmm, I haven't come across those myself yet, but I guess there are people who 
do that.

> 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!"

The main problem with such a person is that they negatively affect all other 
people having the same issue.

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

Absolutely. One thing to keep in mind though is that we often deal with 
language and culture barriers.

> > 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 was just pointing out that options are not always as visible or know as one 
would assume.

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

Yes. Within limits of their problem domain of course.
Obviously not the usual case, just pointing out that coding is not expected 
from even contributors, lest from users, but surprinsingly sometimes they do 
even change code :)

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

Sometimes a program fix is not in code, but in something that a tool generates 
code from, etc.
Or it is a matter of doing things in a different order.
Not always does changing code require writing it.

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/20131029/e9bd745b/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.