Re: [Xen-devel] [PATCH v9 5/6] Clone and build Seabios by default

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2011-12-14 at 16:59 +0000, Stefano Stabellini wrote:
> On Wed, 14 Dec 2011, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH v9 5/6] Clone and build 
> > Seabios by default"):
> > > Unfortunately I expect that distros will want to package qemu once (from
> > > upstream) with support for all the various options, including Xen,
> > > enabled and depend on that in their Xen packaging rather than packaging
> > > a slightly different qemu a second time.
> > 
> > Quite.
> 
> Considering that Qemu releases are not in sync with our releases, I
> think that we should point xen-unstable to one of our own Qemu trees
> rather than just a mirror of the Qemu stable branch on xenbits.
> Otherwise we risk loosing important features, for example if there are
> not going to be any new Qemu releases before Xen 4.2 is out, we are
> going to miss pci passthrough and save/restore, while if we had our own
> branch we would have them.
> Of course it is still very important to keep Qemu stable branches stable
> and functional, so that if distros decide to package a single upstream
> Qemu, it still going to work fine, even though it is going to have fewer
> features.

Agreed, all these trees are very important and therefore we must test
all of them, although perhaps not in the same way as we currently test
things.

How about this:

We host a qemu tree including a staging branch and associated push gate.
This tree tracks the current qemu stable branch and contains backports
of patches which have been applied to the current qemu development
branch (using a policy similar to the Linux stable series policy, in
order to prevent accidental forking). We point xen-devel at this and it
is used by the regular testing machinery and forms part of the Xen
releases.

Then as a separate independent test we periodically (e.g. weekly or
twice-weekly) test the upstream qemu development branch against some
baseline version of Xen (e.g. the most recent pass of either unstable or
current stable branch). This test doesn't gate anything but is just to
keep tabs on the development branch and spot regressions earlier etc.

Lastly we also test any releases (rc and final, perhaps beta) on both
the qemu stable and development branches against current latest unstable
and stable Xen branches. Again this doesn't gate anything but just keeps
tabs on things.

BTW I think periodic test + rc&releases is how we should handle Linux
upstream too and indeed any other external dependency which runs on a
disconnected schedule.

Ian.

> 
> 
> > > > I don't have an opinion on seabios because I am nore sure how many
> > > > changes are we going to make to it. However I recall that you and/or
> > > > IanC were in favor of having or own branch of seabios as well.
> > > 
> > > I think that even if we never diverge from upstream and irrespective of
> > > whether we stick in lockstep or not we should host a tree to point our
> > > users (and default build) at. This gives us flexibility if we ever do
> > > need to diverge and also isolates our users from issues with 3rd party
> > > servers.
> > 
> > Indeed so.  But should it be one tree for each Xen branch, and does it
> > need a push gate ?
>  
> I think we might do without a tree for each Xen branch because we need
> to support building upstream Qemu against Xen 4.2+ anyway.
> Let's say that we have released Xen 4.2, we are now in the Xen 4.3
> release cycle and we want to introduce an incompatible change in Qemu:
> we would need to add a compatibility layer to allow it to build and run
> on Xen 4.2 anyway.
> The difficulty having a single tree would be keeping track of the
> changes only present in our own tree, and possibly revert them before
> pulling new commits from upstream that implement the same features in a
> different way.
> 
> Regarding the push-gate, I am OK with it.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel