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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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).
 * Move the two new trees out of people/ianc into the correct places.
   Ensure git-http etc all works and that Stefano + IanJ have appropriate
   permissions.
 * 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...)
 * Once that change is in osstest.git#production Stefano and Ian would
   switch to pushing to the appropriate staging* branches new trees'.
   osstest will ignore the old staging trees and osstest will update both
   the new master/stable branches and the old stable trees (but not the old
   qemu-upstream-unstable#master branch).
 * 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.
 * At this point we could remove the old staging/qemu-upstream-* trees,
   they are not referenced by anything.
 * 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.
 * 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.
 * Consider hiding (or removing) the old output trees from xenbits as well.

I don't think this has any impact on the 4.6 release, apart from the point
where Stefano+Ian start pushing to the new trees, so we could consider
starting whenever we like.

I don't propose that we try and do the backport of the Config.mk change to
4.6 for 4.6.0, it can wait for 4.6.1.

Ian.

[0] http://mid.gmane.org/<1438266156.11600.347.camel@xxxxxxxxxx>

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