Demand a KDE Experience from your Distribution !

If you are reading this blog you probably know how things work in the GNU/Linux Desktop, some people develop software and then some other people distribute that software. This usually works quite well since the people distributing the software (In this case KDE software) work with us, and together we make sure that the final product is awesome.

This system works as long as both, upstream (KDE) and downstream (Distributions) work together, but some times collaboration does not happen and problems appear. In those cases the experience that the user gets is not the experience we designed from KDE.

This is quite similar to what happens in the Android world, HTC/Samsung/LG do their own versions of it containing a different set of applications, configurations, services, etc. Google then releases what their think Android should be. In the same way Kubuntu/Opensuse/Fredora/Chakra do what they think is correct when it comes to updates, default applications, modify our software etc, meaning that in most cases the software is delivered in a different way from what we envision.

This is why I want you to demand to your distribution to offer a full KDE Experience, this means:

  • Not patching our software.
  • Upgrading to all minor releases.
  • Not using software that is no longer supported by us.
  • Offering all pre-releases as optional.
  • Use the latest supported middle-ware and libraries (bluez, networkmanager, udisk, Qt, virtuoso…)

In order for distributions to do this we need to build some infrastructure we currently lack; what is the latest supported virtuoso? or the latest supported BlueZ? Currently only the respective developers know about these things.

While we work on setting up those bits of infrastructure there are things you can already demand from your distributions – minor upgrades, no patching, or making all pre-releases available.

 

  • Patrick Häcker

    Although I see your reasons for your demand, I cannot follow them completely. Debian, for example, didn’t install Kmail2 when it was available, but decided to stick longer with Kmail1. This allowed me to continue working with KDE while others had less luck (according to several articles and bug reports). I do not want to do finger pointing and I see that at some point software must be tested more widely.
    But as a matter of fact different use cases lead to different stability requirements, which KDE currently cannot satisfy. Different distributions satisfy these different stability requirements. Thus, I think it is an advantage, that there are distributions which do not provide what you define as “full KDE experience”, but that they provide differing KDE experiences.

    • http://www.afiestas.org afiestas

      I do not think that having different flavours of KDE is bad, but I do think distributions should provide a way of having the experience we design, in the case of Debian it could be another repo.

      In the case of KMail they might be right, but in other many many cases they are just offering a poor experience compared to others, for example KScreen or plasma-nm.

      We (upstream) should make a better job deciding what gets the stable tag and what doesn’t, perhaps having packagers in these kind of decisions will be a good improvement.

      • enr

        “We (upstream) should make a better job deciding what gets the stable tag and what doesn’t”

        You should do this first and then ask for “a KDE experience” from distros. Most 4.x.0 releases are very bad, and until 4.x.2 (at least) KDE is not what it should be, so only after you learn to distinguish what’s stable and what’s not, you can ask distros to push your stable software as soon as they can.

        • http://www.afiestas.org afiestas

          Well this is a problem we have.

          Most distros doesn’t ship Beta1.
          Most distros have difficult ways of enabling Beta2/RC’s
          When the time come, we have had little test of what will become 4.X.0
          We end up with a buggy release.

          Maybe distros could install the betas in /opt (or something like that) so we can get more testing and avoid having .0 releases with critical bugs.

          For what is worth, I do think we suffer from a “Works here” problem, for example most of the bugs I fix these days are bugs I do not suffer.

          • http://www.dennogumi.org Luca Beltrame

            Disclaimer: I’m on the openSUSE KDE team.

            Maybe distros could install the betas in /opt (or something like that) so we can get more testing and avoid having .0 releases with critical bugs.

            That would be a huge pain for packaging. In openSUSE we have a specific repository for testing stuff that will then get in the main distro, and doing such a thing just for betas would be a maintenance nightmare. And then, how do you update to stable?

            Don’t forget that also some stuff requires to be in the prefix to work correctly (e.g. Polkit) which will mean conflicts with existing (stable) installs.

            It’s not like I’m dissing the idea, we’ve been playing with this, but it’s much harder than what one would expect.

            • http://www.dennogumi.org Luca Beltrame

              Of course it wasn’t properly quoted…. The part with “maybe distros” ending with “critical bugs” is by the original blog author, not me.

              • http://www.afiestas.org afiestas

                Maybe that repository can be more exposed somehow?

          • RIotingPacifist

            I don’t think most distros make it hard to install RCs , Kubuntu & Arch offer a repository, they are the only two I’ve used recently but http://community.kde.org/KDE_SC/Binary_Packages#KDE_SC_4.12_RC_.284.11.97.29 escribes pretty how to install them for most common distros, perhaps KDE devs could do a better job of talking to downstream and update the release anouncements with the supported way of doing it for common/all distros

            • http://www.afiestas.org afiestas

              Adding a repository is complex task for most people I’d like to target, Imho it should be a matter of checking a checkbox, nothing more.

      • Patrick Häcker

        Debian provides parts of the mentioned infrastructure by having (sort of) different repositories, i.e. “stable”, “testing”, “unstable” and “experimental”, which in (simplified) theory contain more recent software versions in increasing order. If the dependencies allow, they can be freely intermixed, i.e. using mostly testing packages and few experimental packages is possible.

        I think the biggest problem here is the lack of manpower in Debian’s KDE team. Plasma-nm is at least in experimental, thus you might get bug reports from cutting-edge Debian users (a possibly small intersection set). Unfortunately, KScreen, is not even in experimental, so you are completely correct here, you would only get bug reports if users compiled it on their own, which requires time and knowledge. KDE 4.12 is also completely unpackaged in Debian. RCs never get packaged in the official repository AFAIK, probably all due to the mentioned lack of manpower (but note that I am guessing, as I am not involved).

        I just thought about how good testing would look like. Live CDs (in general: a temporary operating system) are interesting, but I think they are not very useful for real world testing. The problem is that real world testing needs real data and real work done with that data and I do not have my data on a temporary OS and avoid the work of migrating/importing/copying that data to the temporary OS. Working with that temporary system with real data and merging the modified data back would be an even larger effort. But without real world data the tests a probably more or less a subset of the tests which the developer does anyway (using at least his own data).

        Upgrading some packages (possible whole KDE) but not the whole distribution to an RC is interesting (parallel installation would be even more interesting, but has problems, as mentioned in other comments). But even if Debian provided the needed RCs (see above), I probably wouldn’t use them. The reason is the following: While I didn’t have problems with upgrading for a while, when downgrading packages you are on your own. When installing an RC, there is always the risk of hitting a bug (that’s the purpose, isn’t it?), which might block getting your work done, so downgrading is a precondition for comfortably testing on real data. This is of course mostly a distribution’s problem, but let’s be honest: Did KDE support downgrading from KMail2 to KMail1 or for other Akonadi-/Nepomuk-related packages? Does KDE support downgrades of other packages (regarding config files and such)?
        That might be an approach to get more testing, but I do not see a motivation for developers to provide this code. Even if someone would write such backwards conversion code, it probably would be poorly tested destroying its purpose.

        BTW:
        When reading most of the comments (my comments included) they sound a bit negative, which is probably quite normal in such a discussion. Nevertheless, I want to highlight that there are a huge amount of positive things around KDE (the people and the software :-)), and especially the progress from the 4.0 times to the 4.10 times and later is very impressive and more than welcome. Thanks a lot for being one of the enabler of that progress!

        • http://www.afiestas.org afiestas

          It is indeed a complicated topic, but we certainly have to work together with downstream to fix it.

          From our side I get the message pretty clear given your and other comments that we need to do better “upgrading path”, your point about KMail1-2 for example makes me thing that in that case we probably needed to be able to use both at the same time, even if that meant duplicating the data.

  • http://csslayer.info csslayer

    While what more ironic is.. the latest middle-wire usually doesn’t support at KDE by the time they are out.

    • http://www.afiestas.org afiestas

      That’s precisely why we need distributions to use middle-ware we do support, if not we end up with a poor KDE experience.

      And btw, it’s been a few releases now that we are pretty much up to speed (UDisk2, Upower1.0, ModemManager 1.0, BlueZ5…)

  • Richard

    +1
    It’s nice that you mention Chakra. (One of) Chakra goals is actually to provide a vanilla KDE experience (also I think they are too small to actually patch each KDE release ;-).

    Especially Chakra’s half-rolling release model fits pretty good with the current KDE SC releases, but even more so for the oncoming kf5. Since there will be no SC’s in kf5 (AFAIK), I actually wonder how non-rolling distros will solve this…

    Oh, and ofc there is also [KDE-unstable] repository and always some brave souls using it.

    /advertisement

    I also tried the other distros (except FRedora ;-) and they also give a very nice KDE experience. Can’t say so much about how up-to-date they are, tho.

    One word about OpenSUSE. They patched the plasma panel resizer, so that you can set the height/width of your panel in pixels. Which is very nice and a very much wanted feature on BKO. However apparently they never bothered to upstream their patch, so I’m missing this now in Chakra. ;-(

    • http://www.afiestas.org afiestas

      Maybe that feature was not accepted upstream, for most people “pixels” is something really hard to deal with so I can see good reasons not to accept that patch.

  • RIotingPacifist

    I’m crossposting this from reddit because in short, I respectfully disagree.

    * Not using software that is no longer supported by us.

    * Use the latest supported middle-ware and libraries (bluez, networkmanager, udisk, Qt, virtuoso…)

    These are only possible if you only support one DE, if DE1 supports v1 of bluez and DE2 supports v1 and v1.5 of bluez which do you use?.

    This is made even worse with

    * Not patching our software.

    If the distro can’t find a set of library versions that support both DE1 & DE2, should it not ship?

    Should it upstream obsolete workarounds and fixes?

    What about distro specific tech?

    We’ve seen how hostile KDE devs are to Ubuntu, but in the more general case? How should a distro deal with missing debug packages for an obscure package manager (perhaps this case is already sorted by packagekit, but there must be some other distro specific technology out there, Yast?)?

    As karper points out in his post http://www.reddit.com/r/kde/comments/1ugpf9/demand_a_kde_experience_from_your_distribution/cehyue1 Arch is very good on the last point (by philosophy**) and good on the first two (by virtue of being a rolling release), however it makes some sacrifices to achieve this. I don’t run arch for a reason and I certainly don’t want all distros to become arch.

    While your post does raise some good aims for distros, I think it was written by somebody who doesn’t see the value distros add, there are two main reasons for this:

    * [The Good] Over time as upstreams have integrated better, software development has improved & communication between projects has become near instant, distro’s have started adding less value themselves. While Arch is great and going forward other distros should learn from it, Debian, RHEL/Fedora, Suse, Gentoo, emerged (no pun inteded) for a reason.

    * [The Bad] KDE is a big framework and you may not be seeing the wider picture ***, sure KDE is great and it’s my favorite DE but it isn’t the only piece of software I use on my computer****.

    Perhaps it’s just that I use Kubuntu and the conversation is better with other distros but Upstream/Downstream is a two way conversation and sometimes it feals if you arn’t using one of the chosen distros this conversation isn’t happening (in particular with release announcements)

    Footnotes:
    * Before some idiot starts crying, please read about Arch and understand that it lightwieght because it comes with very little on the default install CD not because the packages are optimised for lightness (though that may be the case for some AUR stuff).

    ** This is also in part by being a rolling release, there is no need to apply hotfixes/local patches over upstreaming the fix, you can just upstream and wait for the new version before building.

    *** Without ranting or naming names I actually think this happens to a few of the more vocal KDE devs, sure Suse/Fedora/Chkra is a great distro for you/KDE but not everybody wants that out of a distro.

    **** I aptitude 129 of 2565 packages I have installed are under *kde*, this i a very unscientific number as it will miss plenty of stuff and dependencies, but I think it’s safe to assume that no more than 20% of what I do with my computer is KDE related, I also browse (firefox), use CLI tools (countless), play Games, do paperwork (libreoffice (for the moment kde’s offerings are my first choice but for compatibility reasons I often fall back)), compile software(gcc, etc), trying out new stuff (e.g using beta versions of xorg/xinput-evdev and while this isn’t supported or default in my distro the packaging standards and constraints in place allow me to do so fairly easily),

    p.s looks like i went a little footnote crazy, oh well it’s better than one of my lispesq posts!

    • http://www.afiestas.org afiestas

      I will reply you on reddit :p

  • tittiatcoke

    I have difficulties with this post. It is one-sided and totally skips the situation that certain distributions (like Fedora and openSUSE) provide multiple DE’s based on a single base system (including the middle-ware). So gstreamer, bluez, ModemManager, NetworkManager, etc are shared by at least GNOME and KDE (the biggest DE’s). These situations do not leave that much space to move around issues where one of these DE’s are not supporting the required versions of middle-ware that the others require. I am sure that this is also valid for Fedora, but we at openSUSE tried our best to resolve these dependencies the best way possible, by either providing both versions and make them co-installable or to try to create patches to resolve the issues.

    With what you are demanding, this would lead to the situation where a distribution can only support a single DE (in this case this would be KDE) and drop all other DE’s. How does this fit in the world of FOSS and having the choice what to install and what to use ??

    This was never an issue in the past and I am a little surprised that you bring this up now. However I assume that this was caused by the Bluez5 experience where GNOME required Bluez5 and KDE was lacking the support for Bluez5. From my experience it seems that KDE is much slower in adopting newer versions of middle-ware than GNOME is at this moment. As you indicated yourself already some issues have been resolved, but we still have the issue with Gstreamer 1.0 support that is lacking in KDE. Fortunately here we were able to co-install Gstreamer 0.10 and Gstreamer 1.0.

    So instead of kicking distributions about how to provide the right KDE experience, the attention should be on keeping compatibility with GNOME regarding support of newer middle-ware versions.

    As Luca already indicated openSUSE offers diverse repositories where we have git-snapshots of the upcoming KDE version, we are publishing the Beta’s and the RC’s. Almost all openSUSE patches have been upstream’d and we (openSUSE KDE team) are trying to give our users the fullest KDE Experience possible.

    So let’s not create fights/disagreements between distro’s or even worse between DE’s, but lets concentrate on a quick turnaround for supporting newer versions of specific middle-ware.

    • http://www.afiestas.org afiestas

      To your first paragraph, or deciding to not ship BlueDevil for example, imho that’s an unacceptable solution, you could have decided not to upgrade GNOME’s but instead you decided to remove KDE Bluetooth support.

      We are going to continue being slower adopting new middle ware, we do not have the manpower for it, so we have to find better solutions.

      Is opensuse still shipping Yast? If so then that’s far from the KDE Experience I meant.

      We are already concentrated on supporting newer versions, we are not as fast as the authors of those middle-ware that commonly work on GNOME.

      • adrianlmm

        And left all of us who love Gnome out in the cold? No way, maybe kde developers should spend more time working in the core and less time working in other less importan things.

        • http://www.afiestas.org afiestas

          We spend most of the time working on core, the thing is that the people working on those pieces of code do not blog/talk much.

          All my free time I spend on all things hardware related, and trust me we are a good chunk of the overall developer community working only on making hardware “just work”.

          Thing is, it does not matter how fast we write code, we will always be behind even if it is only by a few days or weeks (like the BlueZ5 case).

          Also, we need to catch-up in some areas like PulseAudio, that “steals” time from us working to support newer versions.

          • adrianlmm

            So, align your time with distributions release days, but don’t propose to ship a older versión of GNOME just to include a bluetooth manager.

        • TheBlackCat

          Someone is getting left in the cold either way. Why do gnome users matter more than KDE ones?

          • adrianlmm

            Because GNOME is better tan KDE, of course.

  • ianjo

    If I’m reading this, you are saying that distros should include the KDE apps recommended by upstream. But what to do when those apps are subpar?
    Sorry but I want my firefox/chrome/libreoffice. No the KDE alternatives are not acceptable. (The same thing happens the other way, I always want my kate/konsole, even on ubuntu).
    Right now, I can pick a distro that comes closer to my preferences. But if all distros are the same, my choice is diminished…

    And what about major releases? A distro that wants to stay on 4.9, and there are no more bugfixing releases. Should they not try to patch and fix issues that still come up? Because there are many times where jumping to a newer release is not an option.

    And what about other concerns, such as multimedia backends for phonon? KDE likes vlc right now, but everyone else uses gstreamer. Should a distro ship both?

    I think that if distros are to ship the vanilla “kde experience”, this experience still has a ways to go, and support and bugfixing of stable releases needs to be taken more seriously, no more “oh this slipped no worries it will be on the next major release, so hold on until then”.

    I want KDE to suceed, but right now I’m a disappointed user and ex-ocasional contributor.

    • http://www.afiestas.org afiestas

      About applications: As far as I know we do not recommend the use of rekonq/calligra, but if we ever do I expect distros to offer in some way this apps by default. Maybe as an alternative cd.

      Staying with an unsupported release is not an option, no distribution has the manpower to maintain a minor release (backport all needed patches), so if you stay on 4.9 for example when 4.10.X is released it will be more stable than 4.9.

      About multimedia, Distro should ship whatever the Phonon developers recommend, yes (Fedora for example is switching after talking with the libvlc people)

      I agree about your “kde experience” points, we have a long way to go !

      • http://www.tigen.org/kevin.kofler/ Kevin Kofler

        Nonsense. Fedora is not going to switch to VLC. VLC is not even in Fedora in the first place. We are staying with Phonon-GStreamer, and a Fedora developer (employed by Red Hat) is currently working on getting the GStreamer 1.0 port ready for production.

        As for upgrading to new minor feature releases, Fedora is actually the only distro doing that, all the other distros have strict policies disallowing it. (In several cases, e.g. Debian stable, even bugfix releases are not allowed!) In Fedora, there are now rules discouraging that practice, but we actually explicitly requested permission from the steering committee FESCo to continue pushing those KDE upgrades (because we believe it is the right thing to do) and obtained it. But in most distros, it is just not going to happen, ever.

        • http://www.afiestas.org afiestas

          Please Kevin, I might be wrong and you are totally right on correct me, but avoid using words as “nonsense”, I try to do and talk my best up to my knowledge.

          I said that because of this thread you might not be aware of:
          http://lists.kde.org/?l=kde-multimedia&m=138114865132092&w=1

          There is a reply from Harald (Phonon Maintainer) that says:
          FWIW rdieter and j-b were able to clear up the confusion on IRC and
          apparently there now are plans to get vlc-without-patent-plugins into
          Fedora \o/

          Also, I remember a conversation I’m not sure if with Harald or Dan where one of them told me Fedora was going to switch to Phonon VLC.

          Also, Kubuntu has been upgrading to all minor releases for a few years now. Fedora as Kubuntu has extra points for doing this.

          • http://www.tigen.org/kevin.kofler/ Kevin Kofler

            There are plans to get a cleaned (or “crippled”, some would say) VLC into Fedora (with the patent-encumbered stuff staying in RPM Fusion), but so far it has not happened. Even if we do that, it doesn’t necessarily mean Phonon-VLC will be the default, there was no such decision and I don’t believe we will make one. As you can see from the message you linked, we have a developer working on Phonon-GStreamer upstream now, and we believe it is the right solution in the long run. Almost all the other multimedia stuff uses GStreamer, even parts of KDE (e.g. Kamoso and KDE Telepathy, both through QtGStreamer) and Qt (e.g. QtWebKit). Things need to move to GStreamer 1.0, but there is work ongoing in both Phonon-GStreamer and QtGStreamer to make it happen.

            Also, Kubuntu has been upgrading to all minor releases for a few years now.

            If you mean bugfix point releases, yes (though they take much longer to push them than we do in Fedora, e.g., saucy-updates in on 4.11.3, whereas in Fedora 19 and 20, 4.11.4 went stable on December 20 (and that was slowed down by the Fedora 20 final freeze, we would have been faster otherwise) and 4.11.5 is coming soon, it’s in updates-testing now). But normally, “minor” means the second number (“major” is the first, i.e. the “4″ in “KDE 4″), and there, Kubuntu only offers those updates in PPAs, like most distributions. In Fedora, we try to push those as updates too (e.g., Fedora 20 is expected to get 4.12.1 or 4.12.2 soon, maybe Fedora 19 too; for now, as I said, both are getting 4.11.5).

  • Anonymous

    It’s ironic to blame distros for not providing appropriate middleware as long as the KDE Community tries really hard *not* to name such middleware. Maybe the next release announcement should state something along the lines of “for the best KDE Experience™, we strongly recommend NetworkManager (≥0.9.6), PulseAudio, the Phonon gstreamer backend, …”.

    • http://www.afiestas.org afiestas

      Yes, this is something we should do (all runtime dependencies actually)

  • Kjetil Kilhavn

    I strongly disagree that this should be something one demands. I use openSUSE, and have since it was called SuSE and was in release 7.1 – and I think they have a fairly good solution. There are separate repositories that lets me install the latest and greatest (or other repositories for the latest and most untested) versions. Currently I use KDE 4.12, and I am very thankful that I can make my own choice. However, if I had to choose between using a stable 4.11 which the openSUSE team kept patching and being forced to use upstream’s version I would choose the stability.

    For my work laptop I prefer to use more stable software. It is great that the openSUSE packagers keep patching a version after the upstream development team has quit doing so.

    For my computer at home I can afford to be a bit more adventurous, and thus have a different set of repositories enabled than I have for my work laptop. As a consequence I was without a local mail client for many months after I first upgraded to KMail2. The latest problem is a more mysterious one that occurs once in a while (haven’t figured out enough to report anything yet) where the session will suddenly close and I am brought to the login screen. It happened a few minutes ago while writing this when I (tried to multitask and) opened a WAV file in Amarok.

    My computer skills are above average, but I am no KDE developer (or rocket scientist). If I am going to use free software for my work laptop, I have to be able to (mostly) rely on it being stable. I haven’t used Windows as my (main) operating system for many years, but stability is a requirement (which is why I switched from DOS/Windows to OS/2 in 1994).

    As for software selection: I keep trying Calligra to check if they can offer good support for the OpenDocument formats, but so far I have found it necessary to stick with LibreOffice although things are constantly improving and I may soon be able to try switching to determine which Office suite I prefer based on its features beyond the absolute requirement of good OpenDocument format support.
    Lately I have also tried using Konqueror (and Rekonq) as browser instead of Firefox. Not quite decided yet where that will end. As expected there are advantages (one being KWallet integration) and disadvantages (one unexpected one being that e.g. Joomla complains that it “can’t identify browser version”).

    I have to agree with “ianjo” that I want my LibreOffice and your suggestion would limit my choices – in the worst case it would force me to try Gnome! ;-)

    • http://www.afiestas.org afiestas

      That 4.11 will be more stable than 4.12 is just not true, at least not once 4.11.5 (which usually is the last maintenance release) is done.

      Just to be clear, I am not against choice, I just want distros to offer some way of having the experience we design. In the case of openSUSE it could be another repo called “KDE as KDE intended”.

  • http://www.tigen.org/kevin.kofler/ Kevin Kofler

    I understand that wish, also seeing how some distros are, or were in the past, butchering KDE software. However, you also have to see this from the other side. I am going to talk with my Fedora hat (no pun intended) on here. Unfortunately, there are several technical or practical constraints limiting how far we can comply to your desires in real-world distributions:

    1. KDEs expected dependencies change much faster than the lifetime of a distribution release. It is just not practical to upgrade something like BlueZ to a new major version during the lifetime of a distribution release. Yet, even though Fedora is one of the fastest-moving distributions out there, even in the 13 months a Fedora release is maintained for on average, KDE requires different middleware versions. Transition periods where both versions are supported are sometimes short to nonexistent. See e.g. how when Fedora 20 was released, BlueDevil 2 for BlueZ 5 was experimental and unsupported; now, less than a month later, you announced the impending EOL of BlueDevil 1 for BlueZ 4! Luckily, we shipped Fedora 20 with a prerelease of BlueDevil 2 and were able to easily upgrade it to your RC, which fixes the crash bugs we found. Fedora 19 will be stuck with BlueDevil 1 for the ~6 months it still has to live though. (Of course, Fedora 18 is also stuck on BlueDevil 1, but as it is reaching its EOL on January 14, that’s not a problem.) The problem is even worse for distributions with longer life cycles. So there are only so many things we can do in such a situation:
    * patch new code to work with old libraries (not always possible, e.g., no way this could have worked for BlueDevil, and besides, you don’t like patching either),
    * patch old code to work with new libraries (with the same issues),
    * ship prerelease software when needed for new libraries,
    * ship EOL software when needed for old libraries,
    * drop the offending software entirely (what openSUSE apparently did for BlueDevil; that’s a last recourse we really try hard to avoid at all costs in Fedora!) or switch to the matching GNOME software where possible (which sucks, too).

    2. KDE Plasma Desktop is not the only desktop environment we ship. In the BlueZ case, GNOME now expects BlueZ 5, so we did not have much of a choice. What the BlueZ maintainers actually proposed doing was to package both, but they would not have been parallel-installable, but would have conflicted at RPM level! What this would have meant is that it would have been impossible to install both GNOME and KDE Plasma (at least with BlueDevil; I think the GNOME Bluetooth stuff is no longer optional in these gnome-shell days) on the same machine. This would really have been a worst-case outcome for our users, so we KDE packagers vetoed that proposal, instead going for shipping BlueDevil 2 prereleases, the only way out of this mess. We also had one of our developers (Jan Grulich) discuss this with you, and your feedback at the time was that BlueDevil 2 would be shippable in time for the Fedora 20 release. There wasn’t much more we could have done. And I think it was the right decision, because now, less than a month after the release, the problems we initially had with the prerelease code are fixed. This same concern is also valid for several other components shared between the desktop environments: NetworkManager (which has repeatedly been a source of much worse trouble than we had with BlueZ now), PolicyKit etc. In some cases, we actually had to ship the GNOME component instead of the KDE one for a release or two because the KDE one was not ready in time, a “solution” I really don’t like.

    3. Upgrading is not always allowed by distribution policies. See my reply in a previous thread. It is also not always possible due to dependency issues, see points 1 and 2.

    4. There are several reasons why patches can be needed. One obvious example is getting security patches out between 2 upstream releases. But there are also reasons for permanent patches. For example, KDE upstream does not support installing both kdelibs3-devel and kdelibs4-devel at the same time in the same prefix, the parallel-installability only extends to the runtime portions. We actually fixed things so both versions can coexist. (We need only one hack, which is to move the unversioned library symlinks – only the symlinks, not the versioned shared libraries used at runtime – to a subdirectory where they conflict. Everything else is clean and straightforward.) Unfortunately, the kdelibs maintainers were not interested. (They claim parallel installation in the same prefix is “impossible” due to the symlink issue and thus also refused to fix the other stuff such as conflicting binaries, e.g. makekdewidgets.) Our users sure are interested! Having to uninstall one -devel package to install the other is just not practical, and using different prefixes (as e.g. openSUSE did) is not possible because it would conflict with our distribution packaging guidelines. So a certain minimum amount of patches will always be needed, no matter how “vanilla” an experience we want to give to our users.

    • http://www.afiestas.org afiestas

      As long as patches are upstream I am cool with them. Patching KWallet to disable it (make it a blank password storage instead of encrypted) I am not cool with.

      As for your other points, you are completely right (won’t get into BlueDevil details, in your case you did everything right since you contacted me).

      We need to draft a plan that will allow conservative distributions to keep a conservative (yet maintained) version of things while other distributions can offer stable yet new stuff.

      When I worked on the release cycle proposal one option that seemed to like everybody was:
      -One release every year and supported for a year
      -Releases every 3 months (with maintenance releases every month)

      The quality of all KDE software will keep getting better since we are splitting a lot of the software we produce. Less changes and smaller code base will reduce the amount of bugs.

    • http://www.tigen.org/kevin.kofler/ Kevin Kofler

      By the way, for the parallel installability problem, the latest news are that this is going to be much better with KF5 (coexisting with kdelibs 4), so a big thank you to KDE upstream for actually taking this issue into account!

  • dave

    Create a “reference” KDE distribution.

    perhaps it will be popular or perhaps it will fail.

    Definitely the KDE community will learn more about the world of distributions and can put those lessons back into KDE

  • renoX

    This “demand” is based on the supposition that the KDE project does a good job of providing a good experience by default..
    Seeing the many criticisms on KDE’s nepomuk and the way it was handled (change the software after beta), I’m not sure that this is the case!

  • Pingback: Demanda una experiencia 100% KDE

  • mitcoes

    Please make a KDEoriginal or kdexperience or KDEXP METAPACKAGE, Anyname with your idea deb. rpm AUR, emerge and slack It is open source easy peasy.

    I will download and use it from AUR if it is done

    But as it is open let the distros to decide what to change or adapt. It is their choice
    And perhaps the KDExp can learn from some choices that can be better than the original one or at least a enough good alternative choice.

    Also Klyde metapackages can be done too, what about that project, It would be great for old XP machines 2014 migration

  • jmt

    I am late to the discussion, but I surely will not demand a KDE experience from my distribution. KDE is my desktop of choice, but at any given time, usually only a portion of GUI applications I have running are from KDE. I use Thunderbird for Mail, Firefox and Chromium for web browsing, Pidgin for IM, Libreoffice for Office. KDE provides the shell, and I use krunner, konsole, kate, kile and okular extensively.

    I want my distribution to give me a good overall experience, and as Kevin, Luca and others have pointed out, that involves much more than just caring for one desktop environment. I feel in very good hands with my distribution (openSUSE, but from my experience the same can be said for some others). I have a very good overall experience.

    Do I always want the latest Plasma Desktop release? During the lifetime of a distribution release? No way. I am happy that my distribution provides updated packages, easy to discover, easy to add. But I just don’t bother to always update them, because primarily, I want to get my work done. If a given release is stable and offers what I want, I don’t upgrade.

    I am very thankful for all the developers, testers, document writers, translators from KDE, Gnome, Mozilla, VLC, Apache and other projects for the brilliant work they are doing. But I am also thankful for the work and efforts of the fine people packaging and stabilizing the software within openSUSE, SUSE, Fedora, Red Hat, CentOS, Debian, Gentoo, Arch and others.

    Free Software is about choice. KDE is about choice. People are different. Needs are different. There is no one path everyone ought to follow.

  • della

    @afiestas In general, I can understand some of your arguments, but please note that, without distribution patched, for example we could not properly print our documents double-sided. Most distribution patches (and some are used over years) help to work around problems that really destroy the whole user experience.

    • http://www.afiestas.org afiestas

      Then those patches should be put upstream where they belong, which will have the nice side effect of having all distros enjoying them.

      • della

        Unfortunately, the distribution patches are often not accepted upstream for political or idealistic reasons. KDE, for example, rarely accepts patches working around problems that are actually QT problems. Although I can understand this viewpoint as developer, this behavior completely destroys the user experience in some cases.

        I would, for example, never use an unpatched KDE if I want to print out something with a duplex printer. And that many KDE users want to print something is IMHO not an unrealistic assumption. (My concrete example is https://bugs.kde.org/show_bug.cgi?id=180051 which is unfixed since 2009)

  • http://blog.sudhirkhanger.com/ Sudhir Khanger

    Should we also drop software that are not being actively developed upstream or doesn’t have significant user base?

    • afiestas

      At least not having them by default would be nice imho. Unmaintained software is usually the more buggy.