Re: kwin and NetBSD

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.

>> 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.

> 
> 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.

> 
>> 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 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!

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.

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

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.

Best Regards
Martin