How to handle KDE not respecting YOUR distros requirements?

[Richard Brown]

On 2016-03-25 17:20, Martin Graesslin wrote:
> Hi,
>
> I stumbled over a blog post by a KDE distro packager and want to do a verbatim
> quote of one section:
> "[] does not have a steenking systemd you crazy KDE developer"
>
> I can see there some frustration about Plasma requiring systemd and the distro
> not wanting that. First of all: that's not the case, we don't have any
> dependency on systemd. We have a few runtime dependencies to logind's dbus
> interface (like in this case) and are extremely open to other solutions. For
> example the repository in question also supports consolekit2.
>
> Now what's wrong with the approach in the blog post:
> 1. It creates an us vs. them! Let's not do that, let's work together to solve
> problems. E.g. by raising concerns on this mailing list
>
> 2. Insults don't help your case! If you call devs crazy you don't have to be
> surprised that your distro's use case will be ignored. After all I'm crazy ;-)
> Also it doesn't support your wish to have more supported than logind.
> Reactions like that just manifest the feeling that the non-systemd people are
> a crowd of people which cannot do anything except yelling. Sorry to be that
> blunt.
>
> 3. If your distro doesn't follow what 99 % of all other distros do, don't
> expect we write code for it!
>
> In the case of e.g. logind it's relatively easy: no Plasma dev is using a non-
> logind system. Don't expect that we go the extra mile to support the minority
> cases. If you want to have something else supported, write the code and submit
> patches. We are happy about them. We don't care whether you use logind,
> consolekit or yabadabadu. If there is code for it, we can integrate it.
>
> But please don't expect that new code will consider anything than what is used
> by the vast majority of our users. Don't start jumping around because of that,
> but help us to support more.

I think part of the problem is what is perceived as the 'attitude' of
KDE developers

Without apologising for the other reply to this thread, I think this
is a point where it makes sense to point something out

KDE is not a 'core' part of many ..indeed most.. distributions any
more, and thinking that KDE reserves the right to demand or shape the
dependencies of distributions is an approach that brings with it
friction.

I do hate quoting distrowatch statistics, but I believe them to be
accurate enough to serve the point I wish to illustrate

Of the top 10 Distributions in the last 12 months in Distrowatch, only
one, openSUSE, currently ships KDE as a default option in it's
installer.

Because we all know distrowatch's counting is flawed, even expanding
it to the top 25 only increases that number to two (PCLinuxOS)

So while it isn't "99%", if KDE wants distributions to follow what 90%
of all other distros do, that would be to put KDE as a secondary or
tertiary option, if offer it to their users at all

And that's not going to do KDE, or KDE users, any favours.

My advice would be to change the mindset.
Make KDE easier than the others for distributions to integrate on their stack.
Listen to the pain points from projects like Slackware (#23 on
Distrowatch) and openSUSE (#4 on Distrowatch).
rovide more information upfront and in advance. Include supporting
information, explain *why*. I'm not asking this extra work for the
hell of it, but this is dreadfully important in order to ensure that:

 a) Distributions can be prepared and don't face nasty surprises
suddenly which risk their release schedules and the expectation of
their users.
 b) Distributions can start meaningful, constructive dialogue with KDE
developers and we can really have a two way street where KDE listens
and adjusts to the problems of those trying to distribute it while
simultaneously distributions are happier to bend an adapt to the
desires of KDE developers

Throwing more debug info into cmake isn't going to solve the problem.
That just leads to more breakages for our packagers to have to debug.
This is first and foremost a communication problem.
We need to learn and understand what you are doing and why in order to
be able to deal with it.

I realise that works both ways but, for example with openSUSE, I think
we're doing a pretty good job of communicating what we are doing and
why regarding our two different distributions, and I think it is
therefore somewhat self-explanatory how each treat KDE a little
differently. We have awesome guys like Luca who are so wrapped up in
both KDE and openSUSE there cannot possibly be a case of 'us vs them'
with someone like him acting as a conduit for both of our projects.
Even beyond him, we do our best to be setup in a way to make it easy
to have these conversations, so lets have them, and move on from the
'lists of demands' which I fear has tainted the discussions to date.

The Question I want to see answered is - Where can a distribution find
a comprehensive list of what KDE is dependant on, and in the case of
"optional-but-recommended" dependencies where can we see the
explanation from KDE's perspective and benefits of satisfying that
dependency?

As an aside - if KDE is prepared to be more flexible in order to
support *BSD distributions, where does this attitude that all Linux
distributions should conform to a template of KDE's choosing come
from? It seems to me to be a double standard that seems to be lacking
an anchor in common sense as far as I can parse.

Regards,

-- 
Richard Brown
Technical Lead - openQA
openSUSE Chairman