Re: [Xen-devel] [qemu-upstream-unstable test] 24553: tolerable FAIL - PUSHED

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-01-28 at 15:33 +0000, Stefano Stabellini wrote:
> On Tue, 28 Jan 2014, Ian Campbell wrote:
> > On Tue, 2014-01-28 at 15:08 +0000, Jan Beulich wrote:
> > > >>> On 28.01.14 at 15:30, George Dunlap <george.dunlap@xxxxxxxxxxxxx> 
> > > >>> wrote:
> > > > On 01/28/2014 12:29 PM, Stefano Stabellini wrote:
> > > >> On Tue, 28 Jan 2014, Ian Campbell wrote:
> > > >>> On Tue, 2014-01-28 at 02:16 +0000, xen.org wrote:
> > > >>>> flight 24553 qemu-upstream-unstable real [real]
> > > >>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/24553/ 
> > > >>>>
> > > >>>> Failures :-/ but no regressions.
> > > >>>
> > > >>> QEMU_UPSTREAM_REVISION in xen.git is currently set to 
> > > >>> qemu-xen-4.4.0-rc1
> > > >>> and so will require updating to actually pull this new stuff into the
> > > >>> release.
> > > >>
> > > >> OK. But given that the new code is not part of any RCs, should I wait
> > > >> for the next one? Should we go back to "master"?
> > > > 
> > > > I guess we should have gone back to "master" after tagging the last RC?
> > > 
> > > Correct - this should have happened the moment the first new
> > > commit passed the push gate on the qemuu tree.
> > 
> > There's no need to wait that long -- this can be done in a commit which
> > immediately follows the one tagged as the rc.
> 
> Formally I am not a committer on xen-unstable.

I was meaning that the person cutting the rc should do it.

But that brings up an interesting point. FWIW I think it would be
absolutely fine for the committer responsible for one of the separate
trees to push updates to the bits of xen.git which pull in that code,
specifically the Config.mk bits.

Ian.


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