[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |