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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.


> > > 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