Re: [Xen-devel] [PATCH OSSTEST] Arrange to test migration from the previous Xen version

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("[PATCH OSSTEST] Arrange to test migration from the 
previous Xen version"):
> There are several steps to this:

Thanks.  Much of this is very elegant.

> +select_prevxenbranch () {
> +     local b
> +     local p
> +     for b in $(./mg-list-all-branches) ; do # already sorted by version
> +             case "$b" in
> +             xen*)

Maybe these patterns should be "xen-" ?  In case someone invents a
tree `xenblargle'.

Hrm, I see you took the example of ap-print-url, cri-common and
mfi-common.

> +        # XXX could find latest pass on that branch and attempt to reuse.
> +        #bfiprevxen=...

There is some nascent stuff in my smoke branch which might help with
this.  It's not suitable for public consumption.

> +        # To avoid the need for TREE_PREVQEMU, TREE_PREVOVMF etc we
> +        # only pass tree_xen and revision_xen here and therefore
> +        # pickup the versions implicitly selected by the
> +        # $REVISION_PREVXEN.
> +        #
> +        # XXX I think this doesn't break bisecting over the old
> +        # versions, since the bisectory will set tree_* based on what
> +        # was actually built, not based on this set of vars.

You are correct.

> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -75,7 +75,8 @@ sub extract () {
>  
>      foreach my $part (@parts) {
>          target_extract_jobdistpath($ho, $part, "path_${part}dist",
> -                                $r{"${part}buildjob"}, \%distpath);
> +             $r{"$ho->{Ident}_${part}buildjob"} // $r{"${part}buildjob"},
> +             \%distpath);

I approve.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel