Re: [Xen-devel] [RFC for-4.7] Switching to a single qemu tree each per qemu-xen and qemu-trad

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 30/07/15 15:22, Ian Campbell wrote:
> (CC-ing 2x QEMU maintainers and stable release manager)
>
> The separate trees are a holdover from mercurial, which didn't (at the
> time) have a good in-repo branching model.
>
> I propose that Xen 4.6 should be the last release which uses these split
> trees and that instead we combine them into just qemu-xen.git (upstream)
> and qemu-xen-traditional.git (our old fork), with branches in those repos
> to match our releases. I picked those names to match the libxl interface
> names for these.

Very much +1 with my XenServer hat on.

>
> This will result in one place to get all the qemu stable branches for a
> given qemu type, without having to remember the naming scheme (which is
> counter-intuitive). It will allow easier cherry-picking and produce less
> places for users to look for our code etc.
>
> We could put all branches for both in the same tree but I think we want to
> just let qemu-xen-trad sit quietly in its own corner. Keeping it separate
> reinforces that it is almost completely frozen, also it saves me having to
> think up a branch naming scheme within a single repo.
>
> A proposed mapping for the two tree scheme which broadly follows the
> xen.git scheme is (paths relative to xenbits git root):
>
> qemu-xen-traditional:
>
>     /staging/qemu-xen-unstable.git#master => /qemu-xen-traditional.git#staging
>     /staging/qemu-xen-X.Y-testing.git#master => 
> /qemu-xen-traditional.git#staging-X.Y
>     /qemu-xen-unstable.git#master => /qemu-xen-traditional.git#master
>     /qemu-xen-X.Y-testing.git#master => /qemu-xen-traditional.git#stable-X.Y

And take the change to drop the other random branches in the repository 
By my observations:

$ git remote show upstream
* remote upstream
  ...
  Remote branches:
    ide-write-cache
    iwj.block-extendable-flag
    origin
    qemu
    upstream
    vga-reverse-merge
    xen.netscriptenv


>
>     NB the revision to use is still referenced in xen.git/Config.mk for
>     each branch, no change here.
>
>     XXX why do staging/* exist, and what pushes from staging to the other?
>     Should we ditch one or the other?

This is how staging used to work for the mecurial xen trees.  I presume
therefore that whatever used to be done for the Xen trees are still
being done for the current qemu trees.

>
> qemu-xen:
>
>     /staging/qemu-upstream-unstable.git#master => /qemu-xen.git#staging
>     /staging/qemu-upstream-X.Y-testing.git#master => /qemu-xen.git#staging-X.Y
>     /qemu-upstream-unstable.git#master => /qemu-xen.git#master
>     /qemu-upstream-X.Y-testing.git#master => /qemu-xen.git#stable-X.Y
>
>     These are push gated by their respective qemu-upstream-* osstest flights.
>
> qemu-mainline:
>
>     Upstream remains git://git.qemu.org/qemu.git. 
>
>     /osstest/qemu.git#mainline/xen-tested-master => 
> /qemu-xen.git#upstream-tested
>
>     /osstest/qemu.git should be removed.
>
>     NB this is the same qemu-xen.git as above.
>
> Below is an osstest patch which implements this proposed scheme (I've not
> actually created any trees).

LGTM.

Also suitable adjustments to the landing page at http://xenbits.xen.org/

~Andrew

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