>>> On 03.07.18 at 10:06, <lars.ku...@citrix.com> wrote: > The GitLab discussion was really interesting. Looking at OSSTEST, it > basically performs build test and integration tests on Hardware. Whereas all > these are needed, build testing and testing of functionality that does not > depend on hardware could be done earlier. The ghist of the GitLab discussion > was to "move" build testing - and possibly some basic integration testing - > to the point of submitting a patch. The basic flow is: > * Someone posts a patch to the list => this will start the GitLab machinery > * The Gitlab machinery will do build tests (and the discussion showed that > we should be able to do this via cross compilation or compilation on a real > system if a service such as infosifter is used - @Matt: I can't find the > company via Google, maybe the spelling in the minutes is wrong) > * This could eventually include a basic set of smoke tests that are system > independent and could run under QEMU - Doug already uses a basic test where a > xen host and/or VM is started > * If it fails, a mail is sent in reply to the patch submission by a bot - > that piece has been developed by Intel for QEMU and Linux and could be > re-used > > This would free up time by reviewers and also leads to issues found earlier. > In other words, OSSTEST would merely re-test what had been tested earlier and > would focus on testing on real hardware. Thus, OSSTEST failures should become > less likely. But obviously implementing such a system, even though all the > pieces for it exist, will take some time.
But the problem is rarely with actual build issues, and much more frequently with other hickups. Plus osstest re-testing what had already been tested elsewhere is not going to help osstest's bandwidth. Yet with now 6 stable branches regularly needing testing, bandwidth is an issue. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
