Re: [Xen-devel] [PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree per qemu version (trad vs upstream)

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("[PATCH OSSTEST+XEN 0/1+1] Switching to one qemu tree per 
qemu version (trad vs upstream)"):
> As discussed[0] I think we should move away from having a pair of qemu
> repositories for each Xen branch and instead have a single pair (one for
> qemu-xen and one for qemu-xen-traditional).
> 
> I've prepared a pair of repositories:
> 
>     
> http://xenbits.xen.org/gitweb/?p=people/ianc/single-qemu-repo/qemu-xen-traditional.git;a=summary
> http://xenbits.xen.org/gitweb/?p=people/ianc/single-qemu-repo/qemu-xen.git;a=summary
> 
> These will eventually become, respectively:
>     git://xenbits.xen.org/qemu-xen-traditional.git
>     git    ://xenbits.xen.org/qemu-xen.git
> 
> Note that qemu-xen-traditional does not have an osstest gate, it is gated
> by changes to Config.mk in xen.git pulling in the specific revision.
> 
> In addition to the scheme described in [0] the qemu-mainline test output
> gate changes from:
>     git    ://xenbits.xen.org/osstest/qemu.git#mainline/xen-tested-master
> to
>     git    ://xenbits.xen.org/qemu-xen.git#upstream    -tested
> 
> Thereby sharing a tree with our upstream branches, which I think makes
> sense. The input remains git://git.qemu.org/qemu.git#master, of course.
> 
> I will post two patches in reply to this, the first is for xen.git to make
> the obvious change to Config.mk.
> 
> The second is for osstest to change it to fetch from these new trees and
> push to them, and in addition push to the old trees for existing stable
> branches only (including 4.6).
> 
> I believe the plan for deployment should be:
> 
>  * Today we can already just remove the old staging/qemu-xen-* trees, they
>    are unused (apart from being manually pushed to along with the staging
>    trees, I think).

Yes.  (it needs some consequential changes to my ad-hoc scripts but
that's fine.)

>  * Push the osstest patch (possibly consider a force push? An osstest
>    flight doesn't actually exercise this and it would make coordination
>    with the next step easier...)

A force push would seem fine to me.

>  * ASAP after the osstest patch reaches production push the patch to
>    xen.git#staging. This will cause the xen-unstable builds to use the new
>    output gate. Until this is done unstable builds will continue using the
>    old master push gate, which is not updated after the osstest update
>    (only stable branches are), this isn't a big deal but obviously a
>    smaller window would be better.

Right.

>  * At this point we could remove the old staging/qemu-upstream-* trees,
>    they are not referenced by anything.

Promptly removing things that are unreferenced and not updated would
be a good idea :-).

>  * At our leisure backport the xen.git change to stable branches, probably
>    back as far as 4.2 (when qemu-xen was introduced).
>  * Do stable releases of each of the above.

This will take quite some time.

>  * Drop (one by one or all at once) the push to the legacy stable branches
>    from osstest as stable releases are made referencing the new trees.

I think it would be sensible to do this all at once and to expect to
do it perhaps 12 months from when we start.

>  * Consider hiding (or removing) the old output trees from xenbits as well.

Hiding them would be a good idea.  I wonder if that's possible.

Ian.

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