Running KDE, and being a great fan of this desktop, I perceive urgent needs for some quality assurances not thrown overboard for 'quick fixes'. Software quality does not improve on quick fixes!
It looks like there is too little done on a software quality assurance.
It is like in mathematics: To prove is difficult, usually; to prove the contrary is easy: a single example destroys the validity of the hypothesis.

KDE has had a black spot for years: the desktop search. And various people and at various locations, stated that 'with the next version of Nepomuk the problem is solved'; and bug reports, including my own, were invalidated with 'not using the latest version'. Where that 'latest version' did not work any better than the one reported.

Worse is what has happened as consequence: a totally new effort was undertaken; by a rewrite/rename. Though there was no quality control at all. Everyone just believed that the new code by Vishesh Handa would be the silver bullet.

Serious mistakes:
1. No checks were done that it actually worked on a large scale
2. It was - despite of previous problems with Nepomuk over some years - accepted despite its lack of a general deactivation
3. More programs were allowed to resort to this software as dependency (e.g. Dolphin)
4. (Similar to Heartbleed) Nobody cared to look at what it does / does not: It does not exclude network drives - a fact acknowledged by the author

Now the search engines are full of "... eats all my RAM" / "slows down my PC to a halt" et cetera. 
In my case it is a quadcore i5 that takes almost 10 seconds to bring up an xterm on an otherwise idle machine. Uninstall would remove Dolphin, Kmail and bunch of other useful applications. 
Yes, I am and I have to be connected to some network drives. 

Software quality, and professional approaches have not been applied by the KDE group, since the author acknowledges that network drives are not taken care of; and that a bug report needs to be filed to this behalf. 
Alas, and sorry, but this is real and serious crap. How can a distinguished project like KDE allow unchecked and obviously un-audited code (and concepts) to simply replace other software; when even the author (who looks like a nincompoop in this case) has simply not have the time to think of network drives? And how did nobody else in the KDE project just overlook this problem? And how did everyone else overlook that an untested, seemingly written-from-scratch software enters an update with system-wide consequences (mail and file utilities) obviously un-audited and unchecked?

Yes, bugs can happen; I myself have introduced hundreds or thousands in my own code, for the last 30+ years. One thing has not happened, though: a blind, auto-piloted flight with completely new software in production; hoping and praying it would work,; and not even include a fall-back alternative in case that it might fail.

In a nutshell: It is highest time that the KDE project develops and implements clear software writing and commissioning guidelines, where a fresh program does not immediately and without fall-back alternative take over relevant system functions.
This is not a software problem, it is an organisational shortcoming of serious relevance and implications, and I would hope and wish that the KDE-project immediately starts looking into these  aspects; and creating unambiguous rules on introduction of new software and new features to be based on a complete feature control, roll-back ability and security audits.


Reproducible: Always