How to handle KDE not respecting YOUR distros requirements?

[Richard Brown]

On 28 March 2016 at 00:52, Luca Beltrame <lbeltrame at kde.org> wrote:
>> or maybe even phase 3, as you should be testing stuff before anyone
>> submits anything to a code tree.. There's infinite examples of
>
> (Switching hats to KDE now)
> The main problem is that the CI system is undergoing a complex transition (and
> IMO, too much for a single person to handle) and it's often broken due to that
> (not to mention the quirks of the base distro used, see e.g. libhybris in
> Ubuntu).  This is where more community involvement would help, but I realize
> doing this is a mostly thankless job.

I think GNOME made an good choice using OpenEmbedded for that

It keeps the wrangling with an OS to a minimum, pulls through what
they need and nothing more from various upstream gits, builds it,
tests it..done

Sure, you can achieve something similar with OBS and kiwi. I'd love to
see that considered. And those tools are distribution neutral, so you
could hack something together to use packages for $distro(s) of your
choice

But as soon as you go that route there’s always the chance of
inheriting strange changes from some distribution, such as libhybris
in Ubuntu

The OpenEmbedded route is not quite as capable, but is simple,
lightweight, and relies on nice clean git trees, not distribution
packages.

Which, to be honest, for technical and political reasons, is probably
a good thing for KDE to be testing against :)

Most of the time their testing is useful, beneficial, and quality
improves. I'm not ENTIRELY sold on the GNOME Continuous way of
testing, I personally think that using openQA with an OpenEmbedded
produced image would be many times more beneficial..would actually be
willing to spend time bootstrapping openSUSE's tests over a KDE
OpenEmbedded image if someone went that route.

At the end of the day, when distributions do hit a problem, you want
to be able to turn around and say "our stuff builds and works fine
with this stuff -
https://git.gnome.org/browse/gnome-continuous/tree/manifest.json ....
you guys figure out what you broke"

which is actually a great head start instead of having to wonder
whether or not anyone has ever tested something before shipping it :)