Re: [Xen-devel] Proposed force push of staging to master

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-02-18 at 10:57 +0000, Stefano Stabellini wrote:
> On Mon, 17 Feb 2014, Ian Jackson wrote:
> > George Dunlap writes ("Re: Proposed force push of staging to master"):
> > > On 02/17/2014 12:08 PM, Ian Jackson wrote:
> > > > So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
> > > > xen.git#master and call it RC4.  Comments welcome.
> > > 
> > > Thanks for the analysis.  This seems like a good plan.
> > 
> > I have done this (RC4 is tagged, tarballs are in production).
> > 
> > I also had to force push the change below to xen.git#master.
> > 
> > Can I request that we don't change this back to say "master" until we
> > are done with 4.4.0 ?  Either way we have to update Config.mk with new
> > qemu upstream versions, but if we set this to "master" in between RCs,
> > I end up having to do it as a force push in the middle of the RC
> > production which is out-of-course, error-prone, and suboptimal.
> > 
> > It is IMO better to put a commit hash in QEMU_UPSTREAM_REVISION in
> > Config.mk (updated when the qemu-upstream tree has passed its push
> > gate).
> > 
> > That is I think the best workflow is:
> >   * make a change to staging/qemu-upstream-unstable.git
> >   * wait for push gate to put it in qemu-upstream-unstable.git
> 
> Does this work because the test infrastructure doesn't obey Config.mk?

For the test flights which target testing of new qemu bits osstest
overrides the version to pick up the new stuff.

For test flights which target testing of Xen itself Config.mk is obeyed.

> Otherwise how could the new changes be tested if QEMU_UPSTREAM_REVISION
> in Config.mk is unchanged?

By the qemu specific flights.

Ian.


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