Dan Smith wrote:
KR> For future releases, would it be a good idea to archive the KR> current state of the cimtest tree at the same time a release is KR> snapped of libvirt-cim? This would allow us to preserve the state KR> of the tests and tie them to a given release.
We can, and we could just use a tag for this. However, unless we get closer to an all PASS/XFAIL situation, I'm not sure I see the point :)
That's a good point.
KR> Have the test suite check for the libvirt-cim rpm. If it exists, KR> grab version. Otherwise, assume the providers are the most recent KR> version upstream.
Yeah, I dunno about that. We could definitely embed a version string into one of the providers somewhere (i.e. VSMS) and key off of that. We'd have to assume some base version if it doesn't exist (like for what is in F9 now) of course.
When would you update the version string? Anytime a change goes into libvirt-cim, there's a possibility that the change in behavior will affect the test case. If you want to update a test so that it behaves one way for libvirt releases older than x.x.4 and a different way for releases x.x.4 and higher, then you'd need to update the embedded string every time you check in a changeset. Unless I'm missing what you mean here. Ideally, it'd be nice to use the hg changeset number, but I'm not sure how to make that happen. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com