On Fri, 2019-10-11 at 10:59 +0200, Bjoern Walk wrote: > Andrea Bolognani <abologna@xxxxxxxxxx> [2019-10-10, 04:56PM +0200]: > > This will be useful to test Jirka's changes to how we handle default > > CPU models on more architectures. > > > > The version posted to the list is heavily snipped, but you can grab > > the full one with > > > > $ git fetch https://gitlab.com/abologna/libvirt caps-4.2.0 > > > > Andrea Bolognani (2): > > tests: Add capabilitie for QEMU 4.2.0 on ppc64 > > tests: Add capabilitie for QEMU 4.2.0 on aarch64 > > Although it actually is a pre-4.2.0 version for QEMU, right? I am > confused, because for s390x we once where told that we do _NOT_ want > pre-versions in the capability files? How do we handle those now? We routinely introduce capabilities for pre-release versions of QEMU, because we want to implement support for new QEMU features as soon as possible rather than waiting for the corresponding QEMU release to be out. Of course doing so causes churn, because we then have to go back after the QEMU release has happened and update those capabilities to reflect the actual release, but the benefits outweight the drawbacks so we're okay with it. What we usually avoid is adding capabilities "just because": if adding the pre-release capabilities doesn't allow us to cover more useful scenarios in the test suite, then it makes sense to avoid the churn and introduce the capabilities after the QEMU release is out. In this specific case, as I mention above Jirka is working on a series that will exercise a QEMU 4.2.0-only feature, and having the capabilities for more architectures available will allow him to write tests that ensure the feature doesn't only work on x86; it just so happens that it's more convenient for me to generate these files than it is for him, so that's why these patches are their own series and not part of his upcoming one. > At least, please update the commit messages to reflect the actual > changes. I'm not sure I understand what you're suggesting I should change. Either way, the patches have already been pushed, but if you expand on your concerns I'll certainly keep them in mind next time. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
