| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Daily Xen Builds
David F Barrera wrote:
Test changeset:
changeset: 7293:0f33cbec4e36
tag: tip
user: emellor@ewan
date: Mon Oct 10 13:06:14 2005 +0100
summary: This patch fixes an error in the xm create path when the
Last known good changeset for all platforms: 7069:a172340ae3f3
<snip>
xm-test: This suite provides a framework for testing the Xen userspace
tools.
SUMMARY:
Platform | PASS | FAIL | XPASS | XFAIL |
---------------------+------+------+-------+-------+
FC3pae | 64 | 30 | 0 | 1 |
hs20.1.sles9-x86_64 | 62 | 32 | 0 | 1 |
hs20.2.sles9-x86_64 | 62 | 32 | 0 | 1 |
hs20.fc4_x86_64 | 63 | 31 | 0 | 1 |
x235sles9nonpae | 64 | 28 | 0 | 1 |
x305rh4pae | 63 | 30 | 0 | 1 |
x335fc4pae | 53 | 39 | 0 | 1 |
This is a lot of failures.
Is it perhaps wise, nearing 3.0, that we adopt a policy of running the
various test suites on code before it gets pushed to the public tree?
This seems like requiring passing on xm-test a sane thing to do for the
tools related changes. Is there anything that needs to be done to the
test suites to make this less painful for the committers?
Just to clarify, I'm suggesting that all changes should be checked
(external patches or Cambridge pushes) against the testsuites before
committing. Just seems like it would be a good way to ensure that we
avoid regressing as we near 3.0 release.
I don't think anyone is particularly at fault for the recent
regressions, I just think it's time we adopt a more rigorious commit policy.
Thoughts?
Regards,
Anthony Liguori
-- Regards,
David F Barrera
Linux Technology Center
Systems and Technology Group, IBM
"The wisest men follow their own direction. "
Euripides
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home