How to handle KDE not respecting YOUR distros requirements?

[Thomas Pfeiffer]

On Dienstag, 12. April 2016 14:11:16 CEST Richard Brown wrote:
> 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)

See, that is the problem: Neither does KDE, and we most likely won't have the 
resources to get one any time soon.

Problems with hardware configurations are - as Martin already said - one of the 
biggest reasons why we still rely on manual testing by our users. We don't 
like this situation, either, but we currently don't see any way around it.

Should openSUSE at some point be fortunate enough to have such a testing rig 
in place for your own testing, we would of course be eternally grateful if we 
could maaaybe run our tests on it as well. 

Our "Commitments of a KDE Project" document [1] states that "Online services 
associated with the project are either hosted on KDE infrastructure or have an 
action plan that ensures continuity which is approved by the KDE system 
administration team". That does not mean we can't run tests on other 
organizations' systems, though. It just aims to ensure that, should anything 
happen which makes these systems unavailable for our tests in the future, we 
can easily move them to someplace else
I'm sure such an "action plan" could be devised with openSUSE, though.

So, this is basically where we're at: Everybody is willing to improve the 
situation, but in the end it comes down to the filthy lucre (in this case 
available hardware).
Maybe we can find a creative solution to this problem? Maybe jointly ask for 
hardware donations from all our stakeholders (including users who might have 
older - but still relevant - hardware to spare)?

It would be great for all of us if we could somehow solve this problem!
Cheers,
Thomas

[1] https://manifesto.kde.org/commitments.html