On Thu, Jul 30, 2020 at 07:50:39AM +0000, Nadav Amit wrote: > > On Jul 30, 2020, at 12:35 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > > On 30/07/20 09:13, Wanpeng Li wrote: > >>>> I personally dislike renames as you will have old references lurking in > >>>> the internet for decades. A rename will result in people continue to using > >>>> the old code because the old name is the only thing that they know. > >>> > >>> +1 for keeping the old name. > >>> > >>> cpu-unit-tests might also not be completely fitting (I remember we > >>> already do test, or will test in the future I/O stuff like PCI, CCW, ...). > >>> > >>> IMHO, It's much more a collection of tests to verify > >>> architecture/standard/whatever compliance (including paravirtualized > >>> interfaces if available). > > > > Good point. > > > >> Vote for keeping the old name. > > > > Ok, so either old name or alternatively arch-unit-tests? But the > > majority seems to be for kvm-unit-tests, and if Nadav has no trouble > > contributing to them I suppose everyone else can too. > > Indeed. My employer (VMware) did not give me hard time (so far) in > contributing to the project just because it has KVM in its name. We (VMware) > also benefit from kvm-unit-tests, and Paolo and others were receptive to > changes that I made to make it more kvm/qemu -independent. This is what > matters. > > So I am ok with the name being kvm-unit-tests. But I would ask/recommend > that the project description [1] be updated to reflect the fact that the > project is hypervisor-agnostic. Good idea. Although while I authored what you see there, I don't really want to sign up to do all the writing. How about when we create the gitlab project we also create a .md file that we redirect [1] to? Then anybody can submit patches for it going forward. > > This should have practical implications. I remember, for example, that I had > a discussion with Paolo in the past regarding “xpass” being reported as a > failure. The rationale was that if a test that is expected to fail on KVM > (since KVM is known to be broken) surprisingly passes, there is some problem > that should be reported as a failure. I would argue that if the project is > hypervisor-agnostic, “xpass” is not a failure. We can use compile-time or run-time logic that depends on the target to decide whether a test should be a normal test (pass/fail) or an xpass/xfail test. Thanks, drew > > So it is much more important how the project is defined than how it is > named. > > [1] http://www.linux-kvm.org/page/KVM-unit-tests
