kwin and NetBSD

Thu Feb 6 17:39:04 GMT 2020

On 06.02.2020 17:47, Martin Flöser wrote:
> Am 2020-02-05 20:56, schrieb Kamil Rytarowski:
>> We have got an active maintainer of the KDE stack in pkgsrc, but I don't
>> know if there are cycles to interact with upstream and show signs of
>> life from our side. Almost all of the qt5/kde5 software works as is on
>> NetBSD. Until
> 
> The minimum would be to subscribe to kde's distribution mailing list
> (https://mail.kde.org/mailman/listinfo/distributions ). Especially for
> KWin I used to announce important changes way ahead there.
> 

Acknowledged.

>>> I know and understand that BSDs
>>> are not up to the development speed of the Linux stack. But it's
>>> unreasonable to expect upstream to take care of it years later. My
>>> personal suggestion is to carry this as an out-of-tree patch in NetBSD.
>>
>> I object here. As an experienced maintainer (in various places, not just
>> NetBSD), every single small patch is a constant cost for downstream
>> developers and users.
> 
> And I can say the same other way around: every ifdef is a constant cost
> for the upstream project. As seen in the commit I did there we were not
> able to ensure it's buildable.
> 

Not really. Support for every new platform can show whether code was
well designed. Recently SerenityOS GUI stack was ported to a BSD kernel
and it worked nicely without a maze of ifdefs.

>>
>> It is better to rather look for adding a NetBSD dedicated buildbot in
>> the project. We try to increase our testing coverage in critical
>> projects and we managed to deploy our patches into tricky upstreams (not
>> naming them here).
> 
> I fully agree that this is something that is needed. With FreeBSD the
> situation significantly increased since it's CI covered. But this was an
> effort pushed by FreeBSD developers. Please do not expect that KDE
> starts to setup a NetBSD jenkins instance. Please also do not expect
> that anybody would fix issues. If something on FreeBSD was broken I
> usually pinged the FreeBSD developers to fix it. Sorry we don't run BSD
> and it's nothing we can actually do. I used to introduce linux-isms
> without even knowing it. And totally honestly I don't think that
> upstream projects need to care about this any more. I think you already
> noticed this that other projects also don't care anymore about being
> Linux specific.
> 

I'm familiar myself with buildbot testing, not with jenkins/java. If it
would be a buildbot we could run it on The NetBSD Foundation machine
same as we do for other projects.

If this must be jenkins, we will need to manage.

>>
>>> For me as former KWin maintainer it was always a mantra that we do not
>>> have distro specific code and only features which Debian supports
>>> (Debian as the linux distribution having support for most packages,
>>> being rather slow and also supporting multiple competing integration
>>> solutions).
>>>
>>
>> BSDs are not just distros of Linux comparable to Debian, they are
>> distinct independent Operating Systems. It is unreasonable to expect
>> e.g. QNX developers to run unmodified on the Linux stack (if someone
>> wants Linux, it's easier to pick the original copy).
> 
> To me it's a downstream which distributes our software. Thus it's a
> distro from my point of view. If you consider yourself as another OS you
> will be treated by someone like me like I treat Microsoft Windows which
> means "I don't care".
> 

We are another OS. And Linux to us is like OpenVMS or Windows, but there
are similarities.

Please note that OpenVMS has/had X11 stack and could run KDE (in
theory). Maybe it ever did?

But from another point of view we are an Open Source distribution if
this statement makes some happier.

>>
>> We already maintain our patches in various non-trivial software stack
>> (including qt5, firefox, LLVM, GCC etc).
>>
>>> But of course this is up to the current development team. If a patch
>>> exists it can be reviewed for its merits.
>>>
>>
>> Actually, I reached you to get a hint how would you like to support it?
>>
>> kwin looks pretty much looks like an elaborated wrapper around
>> libudev+libinput so a suggestions how would you like to see it
>> implemented are welcome.
> 
> Quite correct, which is also the reason why reverting the patch is not
> sensible.
> 
> I do not think that KWin should gain a second input stack. This would be
> a significant burden for development and would always just be a second
> class citizen. This is something you should be aware of!
> 

I presume you mean that regressions on !Linux shall be handled by !Linux
developers.

> The IMHO only sensible approach would be to turn the libinput stack into
> a plugin and allow multiple plugins. This would allow you to provide
> your own input stack plugin. But I really think this needs to live
> downstream. Though if this is well enough capsuled I could imagine it go
> into KWin's source tree. But if it's only for BSD's you need to be aware
> that this won't be maintained as that's just outside of our scope.
> 

If we would be looking for forks and downstream development fragmenting
the overall community, we wouldn't reach you in the first place.

Please note that we maintain pkgsrc that is a multi-OS packaging system,
used in Linux, BSDs, Illumos, Darwin.

> Please be aware the udev is also required for getting the drm stack up
> and running.
> 

Thank you for noting it. I will research it.

> Sorry if this all sounds rather harsh, but I think it's important to get
> the expectations right. From our upstream perspective best would be if
> you would provide a compatibility layer. For something like that we are
> open. E.g. we added support for alternatives to logind.
> 

Actually, I think, looking at kwin... that it might be easier to rewrite
our input & event system to behave more similarly to libinput+libudev
and offer similar and when possible same interface.

If we would be down to ifdefing features that behave similarly it would
be much easier to maintain it.

> Best Regards
> Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kwin/attachments/20200206/f3816494/attachment.sig>