How to handle KDE not respecting YOUR distros requirements?

[Richard Brown]

On 12 April 2016 at 13:21, Martin Graesslin <mgraesslin at kde.org> wrote:
> On Tuesday, April 12, 2016 12:42:41 PM CEST Richard Brown wrote:
>> 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.
>
> so you have multiple hardware like one server with
> * Intel IvyBridge
> * Intel SandyBridge
> * Intel Haswell
> * same matrix for AMD cards
> * same matrix for NVIDIA cards
> * in the last two cases running all tests with prop and free driver
>
> That would be awesome!

For something like that you'd need an openQA server, several IP KVM
devices like the adderlink-ipeps, then at least 1 physical machine for
each of those different cards you want to test

openQA can happily handle the OS & driver installs

_In theory_ you can remove the need of the IP KVM devices and the
physical machines by using techniques like
https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF

But I don't have a server full of graphic cards to play with the idea
(We do have full OVMF support in openQA, that's how we test UEFI, so
it certainly appears feasible)