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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.01.14 at 16:31, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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.

Except that it might end up being pointless if nothing really
changes in qemuu until the next RC (or the final release).

>> Don't know whether there would be a way to automate this...
> 
> It sounds like it would be tricky. I suppose a cronjob which verifies
> that xen.git/staging always either says "master" or refers to a tag
> which is the latest in qemu.git might work, but it sounds subtle and
> error prone to me.

Yes, I realize there would be a number of "special" situations to
take into consideration...

Jan


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