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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 15 Dec 2011, Ian Campbell wrote:
> > 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.

I am OK with this, if everything goes well we shouldn't need anything
else. It might happen that because of time constraints we have to apply
patches to this tree before they are applied upstream, but it should
only be the exception, not the rule.


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

twice-weekly would be good


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

indeed

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