How to handle KDE not respecting YOUR distros requirements?

[Richard Brown]

On 12 April 2016 at 11:04, Martin Graesslin <mgraesslin at kde.org> wrote:
> On Sunday, April 10, 2016 10:41:20 PM CEST Richard Brown wrote:
>> Is there anyone from this list going to be taking me up on this offer?
>
> our sysadmins who would have to setup an openQA infrastructure live in
> Australia and USA/west coast. I doubt they will attend openSUSE conf.

That's a shame :(

>> I'm working on the abstract for my proposal to the CFP and I want to
>> get the balance right between either a general openQA talk or if I
>> should be putting a KDE spin on it if there is going to be people from
>> here attending it ;)
>
> I have not yet decided whether I will go to openSUSE conf. In general I'm very
> interested in openQA and similar technologies. Especially to know whether they
> provide an additional benefit over our current test infrastructure at
> build.kde.org. Our biggest areas of quality issues are things like:
> * what happens when you physically unplug a screen
> * what happens if new Qt version regressed in multi-screen handling
> * what happens if the Intel xorg driver regressed [1]
>
> Do you think OpenQA could help us detect these problems automatically? If so,
> I would be very interested to learn more. If not, we may have to look for
> other solutions, after all.

Driver Regressions - Yes. We have the 'GeneralHW' backend which allows
us to use arbitrary IP KVM VNC devices (eg
http://www.adder.com/products/adderlink-ipeps ) to look at the real
VGA output of actual video cards. This is already fully implimented
and used inside SUSE.

Physical Unplug - Yes. Using QEMU's device_del function we should be
hotplug and unplug video cards. This will need a little bit of openQA
backend work to make viable, but not much.

Multi-screen handling. Yes in Theory . openQA typically looks at only
one screen at the moment, but there is no reason we couldn't expand
it.

> Especially the fact that one can hardly auto-test xrandr is a huge problem to
> us. On the other hand we work a lot on making this testable - our Wayland
> efforts are completely designed around making this testable. With KWayland
> having a line test coverage of > 80 %, kscreen having dedicated test
> infrastructure allowing to feed in configurations. That's all things our
> current infrastructure can already handle.

Do your tests actually confirm that it's working from a users
perspective though? Can I see some examples? I'm curious

>
> Cheers
> Martin
>
> [1] This is truly the biggest problem we have at the moment. At least once
> every two weeks I have to investigate some weird regression in a distribution
> and it always boils down to Intel driver regressed. That are things like
> * session manager not starting at all
> * random freezes
> * rendering artifacts
> * random crashes in random applications
>
> _______________________________________________
> Distributions mailing list
> Distributions at kde.org
> https://mail.kde.org/mailman/listinfo/distributions
>