[libvirt] [PATCH 0/2] tests: Add capabilities for QEMU 4.2.0 on ppc64 and aarch64

[Andrea Bolognani]

On Fri, 2019-10-11 at 10:59 +0200, Bjoern Walk wrote:
> Andrea Bolognani <abologna at redhat.com> [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