Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jul 03, 2018 at 10:14:06AM +0000, Lars Kurth wrote:
> 
> 
> On 03/07/2018, 11:01, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>     >>> On 03.07.18 at 10:06, <lars.kurth@xxxxxxxxxx> 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.
>     
> OK, I didn't realize bandwidth is the primary issue. If it is, we can fix 
> this part by throwing more HW at the problem.
> Let me have a chat with Ian when I am in the office and come up with a list 
> of issues from his perspective and feed this back into the thread.

Throwing in more hardware is good, but that also bring more hardware and
(non-Xen) software related issues. We need to weight carefully pros and
cons on this.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel