xen.org writes ("[xen-unstable test] 24870: regressions - trouble:
broken/fail/pass"):
flight 24870 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/24870/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-oldkern 3 host-build-prep fail REGR. vs. 24862
This was the "usual" failure: Citrix's intercepting web proxy causes
some hg clones of linux-2.6.18.hg from xenbits to fail. The rest of
the flight was successful.
The rest of the weekend's tests were badly affected by a disk failure
on earwig. So as a result we didn't get a push.
I cleared out a bunch of other stuff running in the test system in an
effort to get a pass sooner, but peeking at the results the same job
has failed the same way in the currently-running flight. So we won't
get a push in that iteration either.
We should consider doing a force push for RC4. The risks are:
* There is something actually wrong with xen.git which causes the
32-bit 2.6.18 build to fail;
* Less resistance in the future to 2.6.18 build failures.
I'll discuss these in turn.
The build-*-oldkern tests involve using the kernel-building machinery
in xen.git to clone 2.6.18 from xenbits and build it. Firstly, I think
it's unlikely that anything in xen.git#d883c179..4e8d89bc would affect
that. Secondly, the build-amd64-oldkern builds have passed. So I
think we can almost entirely discount the first risk.
I think the second risk is tolerable. We should keep an eye on it for
a bit and if it turns out that the oldkern build really does become
broken later and as a result keeps failing indefinitely, we will be
able to spot that.
So, we propose to push 4e8d89bc1445f91c4c6c7bf0ad8d51b0c809841e to
xen.git#master and call it RC4. Comments welcome.
