* Avi Kivity<avi@xxxxxxxxxx> wrote:
So instead you force a NxN compatibility matrix [all versions of qemu combinedHappy choice or not, this is what i said is the distro practice theseSo in addition to all the normal kernel regressions, you want to force
days. (i dont know all the distros that well so i'm sure there's
differences)
tools/kvm/ regressions on users.
with all versions of the kernel] instead of a linear N versions matrix with a
clear focus on the last version. Brilliant engineering i have to say ;-)
Also, by your argument the kernel should be split up into a micro-kernel, with
different packages for KVM, scheduler, drivers, upgradeable separately.
That would be a nightmare. (i can detail many facets of that nightmare if you
insist but i'll spare the electrons for now) Fortunately few kernel developers
share your views about this.
I think you still dont understand it: if a tool moves to the kernel repo, thenNo, I am suggesting qemu-kvm.git is not as stable as released versions (andI don't mind at all if rawhide users run on the latest and greatest, butWhat are you suggesting, that released versions of KVM are not reliable?
release users deserve a little more stability.
Of course any tools/ bits are release engineered just as much as the rest
of KVM ...
won't get fixed backported). Keep in mind that unlike many userspace
applications, qemu exposes an ABI to guests which we must keep compatible.
it is _released stable_ together with the next stable kernel.