Yet another failed KDE release?

Kevin Krammer krammer at
Tue Apr 2 13:13:43 BST 2013

On Thursday, 2013-03-28, Kevin Chadwick wrote:
> On Wed, 27 Mar 2013 21:21:47 +0100
> Kevin Krammer <krammer at> wrote:
> > > I certainly think should change it's name perhaps to
> > > or maybe
> > 
> > I didn't get the context of that one.
> Various projects have shown their disregard for the user base and
> preference for enterprise or cloud things like:
> Udisks - dropping support for 6 months for features people actually
> use in order to cater for sessions (it may be Arch using udisks2? before
> it should have done was the problem there however, Arch has some good
> but also terrible points)
> systemd - perhaps not a spec? but it certainly abuses
> the domain without allowing comments and has basically
> come from Red Hats want for spinning up VMs quickly, disregarding other
> priorities of the main user base.

Well, I haven't had any problem with either, i.e. udisk working well and not 
using systemd yet, but neither is related to the project or 
efforts, simply using the infrastructure for hosting.
As far as I know the involved developers are mostly kernel/system level people 
who might have a different focus than end user application developers.

I just don't think it would be worth the effort of building another 
infrastructure provider (repositories, mailinglist, bug trackers). Most likely 
new project that do not want to share infrastructure with established FOSS 
projects will nowadays go for github or gitorious (assuming they now also 
provide bug trackers and mailinglist).

> It doesn't suit the name freedesktop because it is forcing more and
> more dependencies such as polkit onto users when it could allow you to
> choose and change to whatever you want when you want like spacefm
> allows you to choose polkit/udisks, sudo/whatever with udevil etc..

Well, any kind of optional feature requires build time checks and guarded code 
section or the design, implementation and maintenance of a plugin system.
Not all projects have the man power to do that and can then either decide not 
to do something or chose one possible way of doing it.

For example KDE's Solid framework allows application developers access to 
disk/volume discovery/management on different base systems (HAL, udisk, 
udisk2), but that of course only helps application developers using Qt.

Developers on other stacks, e.g. IIRC those working on Thunar filemanager, had 
to decide to drop HAL support.
They certainly didn't do that without cause, they most likely decided on the 
best possible option regarding their use case and available resources.

> > > especially as I am skeptical of it being implemented well
> > > considering freedekstop.orgs history such as disregard for other
> > > opinions and anything non linux
> > 
> > Hmm, can you point out a spec which is bound to Linux?
> > Qt and KDE implement most of them can run quite nicely on BSDs as far
> > as I heard.
> I guess I am meaning freedesktop hosted and my above gripe may actually
> be with the desktop environment dependencies that have nothing to do
> with specs but happens to be common to varying degrees
> to all the DEs that use the specs. Perhaps you could confirm that for
> me?

Hosted projects do whatever they need to do to realize their goals. At some 
point in history it was consider political suicide to be hosted on e.g. GNOME 
or KDE infrastructure because tons of people would falsly assume all kinds of 
We can still see this occasionally when Qt based application developers start 
implementing libraries that already exist, well tested and maintained, in 
KDE's git repositories.

Going for "neutral" hosting was often an attempt to avoid that, especially 
when company run solutions like SourceForge where deemed unfit for whatever 

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: <>
-------------- next part --------------
This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list