How to handle KDE not respecting YOUR distros requirements?

[Eric Hameleers]

On Sun, 27 Mar 2016, Martin Graesslin wrote:

> On Friday, March 25, 2016 1:42:30 PM CEST Eric Hameleers wrote:
>> On Fri, 25 Mar 2016, 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.
>>>
>>> Thank you!
>>> Martin
>>
>> Thank you for affirming your moral superiority, again.
>>
>> A few posts ago there was a lot of brouhaha about the realization that
>> KDE developers should take care not to leave the BSD's in the cold -
>> and the next moment you are telling me that Slackware (which is what
>> we are talking about) is to blame for not accepting systemd and that
>> all the consequences are for us because you are not going to support a
>> minority Linux distro?
>>
>> Way to go Martin.
>
> Hi Eric,
>
> could you please tune down a little bit? Thank you.

Hi Martin, thanks for replying, it's appreciated.

> If you read my mail again you will notice that I did not mention Slackware at
> all. I shortened the quote from your blog post to not include the distro name,
> because I didn't want to give blame to anyone. I wanted to address the us vs.
> them attitude expressed in your blog post.

Put the quoted text into Google as everyone will have done after 
reading your email, and it is pretty obvious what the source of your 
complaint was. You are no different than me - instead of writing this 
public shaming on a mailing list, you could have written a 
comment on my blog, or even contacted me directly via email.

I think that by now it has been established that all involved parties 
will have to move away from the "us versus them" attitude. Your reply 
helps, so I will follow suit. Note however, that there is a functional 
"us versus them" that will remain. I am not part of your KDE developer 
community and I see it as one of my duties to point out the fallacies 
in your development process. KDE is not making it any easier for "us" 
distro packagers by abandoning the co-ordinated releases and moving to 
a form of agile coding that results in distro-packager mailing list 
being flooded by workarounds for program X which is released before 
the code it depends on (in frameworks or plasma or applications) is 
released. I used to tell everybody how simple and straight-forward KDE 
packaging was compared to other big products (DE's and others) but 
since last year you won't hear me telling that anymore.  In fact, 
every time you guys bump release numbers, I am at a point where I have 
to consider "is this where I just quit packaging KDE code". This is a 
"use versus them" state of mind that I would really get rid of, but it 
requires an effort from the developers. You are either writing the 
code for yourself and your own KDE OS, and then other distros become 
irrelevant, or you write your code to be used by others and then you 
really have to interact pro-actively in order not to be confronted 
with an uproar after the fact.
End of rant.

> Now lets look at what we have here. The functionality in question was
> introduced with https://git.reviewboard.kde.org/r/124915/ - you will notice
> that we did not consider the case that a system doesn't have loginctl at all
> (this is absolutely not about sytemd, really not!). At the same time we looked
> at variations in distros like whether you have sudo or not. Most likely it was
> a plain oversight caused by us living in our own little bubble ;-)

More than likely so. I have been thinking about how (as a packager and 
a enduser, not as a developer which I am not) I should handle the fact 
that my upstream has a natural focus on his majority target 
audience. Perhaps a more informal communication is required, but I 
guess you do not want every minority downstream entity filling your 
personal mailbox.

So, I will probably have to remain in a re-active mode instead of 
working pro-actively: meaning that I will see the result of your 
coding only after building the distro package and deploying it on my 
computers and Slackware Live. Which means, inbetween packaging and 
making the packages available to my own target audience, there will 
not be time to create a KDEBUG, waiting for triage and a possible fix. 
The packages will have been made available well before  that. And 
knowing me, I will be vocal about the changes that frustrate me 
when it is obvious they should not have been necessary.

> Which means also the BSDs currently see the same message. There is no first
> class/second class going on.
>
> If you read my mail again I also don't blame Slackware to not use systemd. To
> repeat again: "We don't care whether you use logind,
> consolekit or yabadabadu"

I know, and previous replies to the list have established that, too. 
The infuriating thing is that message on-screen, making assumptions 
about me, my OS and my system. One of Slackware's paradigms is 
"Slackware does not assume anything" - it empowers the enduser. 
Informing me that 'my screenlocker is broken' and to 'use loginctl' is 
not what a screenlocker error handler should do. Instead, it should 
show a meaningful message about the nature of the error so that I  can 
start troubleshooting (or file a bug). It is then up to the distro to 
document this case and instruct the user to mitigate or fix the issue 
by running program X or command Y.

> And I mean that! It's not just empty words. We did accept the consolekit2 code
> without any discussions, in fact on the very first review request about
> consolekit2 I asked whether the dev would please also add integration into
> kscreenlocker and kwin, see https://git.reviewboard.kde.org/r/124388/

Yes and I was, and am, glad about that. Without the collaboration with 
the CK2 team, Slackware would never be able to migrate to Plasma 5. 
Would you cheer when a distro drops your work because you did not care 
enough about your downstream users? I guess not! KDE  Plasma 5 is a 
grand piece of software which I use every day and do not want to 
lose because for obvious reasons I am sticking with Slackware. I am 
also using Gnome 3 on a daily basis on another OS and I have no love 
for that DE.

> So I kindly ask you as well to please stop assuming we want to force anybody
> to use systemd. The only thing we ask you is to raise such issues on our
> mailing list - either this one or more developer specific. If you don't tell
> us, we don't notice it's a problem.
>
> And here it's absolutely important to get your work. We don't have a system
> without logind. We won't be able to test a patch. I don't even know whether
> the respective feature can work at all without consolekit2 or logind. So
> please come to us and give us the input. But don't rant, not even on your
> distro blog post which we are not supposed to ever see.

I rant whenever I think it is necessary. In this case, it was 
necessary. Do not make assumptions about your downstream please. It is 
percieved as condescending, even if that was not your intention.

I am making Live ISOs available of our development release, with 
Plasma 5 stuck on top instead of Slackware's own KDE 4: 
https://community.kde.org/Plasma/Live_Images#Slackware . This allows 
people to test without having to install. I build a collection of 
Frameworks, Plasma and Applications once a month and refresh the Live 
ISO with them. Feel free to give it a spin.

>> I do not see how this is an insult, sorry Martin.
>
> I wrote the patch in question, of course I read that as a personal insult
> calling me crazy. I hope you can imagine how it must feel to me reading your
> blog post, seeing my (useful) feature described like that, me as the developer
> attacked. If you don't want to insult devs, don't write like that.

I think you are as vocal about your beliefs as I am about mine, so 
shall we leave it at that? Looking forward to our next diatribe. You 
are hereby invited to drinking a beer with me whenever you visit the 
Netherlands.

Cheers, Eric

-- 
Eric Hameleers <alien at slackware.com>
Home: http://alien.slackbook.org/blog/