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(a)linux.vnet.ibm.com