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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design 
session] Process changes: is the 6 monthly release Cadence too short, Security 
Process, ..."):
> Same applies to the host: the base system (without the to be tested
> component like qemu, xen, or whatever) could be installed just by
> cloning a disk/partition/logical volume.

Certainly it would be a bad idea to use anything *on the test host
itself* as a basis for a subsequent test.  The previous test might
have corrupted it.

So that means that often, and at least from one test flight to the
next, all of the base dom0 OS needs to be copied from somewhere else
to the test host.  This is not currently as fast as it could be, but
running d-i is not massively slower than something like FAI.

To a fairly large extent, similar considerations apply to guest
images.

> Each image would run through the stages new->staging->stable:
> 
> - Each time a component is released an image is based on (e.g. a new
>   mainline kernel) a new image is created by installing it. In case this
>   succeeds, the image is moved to the staging area.

This would happen a lot more often than you seem to image.  "Releaed"
here really means "is updated in its appropriate git branch".

Unless you think we should do our testing of Xen mainly with released
versions of Linux stable branches (in which case, given how Linux
stable branches are often broken, we might be long out of date), or
our testing of Linux only with point releases of Xen, etc.

The current approach is mostly to take the most recent
tested-and-working git commit from each of the inputs.  This aspect of
osstest generally works well, I think.

Ian.

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