Lucky they're not the ones accepting patches. If upstream adopts it they'd have to disable support in their build, which seems unlikely.
I wouldn't read WONTFIX like that for anything downstream (i.e. a distribution bug tracker for projects they package). It's we won't do it, not noone else can. WONTFIX only means WONTFIX if that's in the one true source of the project, i.e. upstream.
RH usually have a lot of not-upstream patches though (at least they do for the kernel, grub, and qemu, so I assume the same for libvirt) which complicates things a bit.
> Lucky they're not the ones accepting patches. If upstream adopts it they'd have to disable support in their build, which seems unlikely.
Upstream libvirt would probably be Red Hat employees. :) It would not be disabled in the RHEL build, but note that Red Hat does disable a lot of features of QEMU in RHEL. About this:
> RH usually have a lot of not-upstream patches though (at least they do for the kernel, grub, and qemu, so I assume the same for libvirt) which complicates things a bit.
Most of the patches in kernel and QEMU are backports from upstream.
For QEMU there are 20-30 patches not-upstream patches and they're mostly configuration. For the kernel it's a bit more but not many, and Libvirt probably has even fewer.
I wouldn't read WONTFIX like that for anything downstream (i.e. a distribution bug tracker for projects they package). It's we won't do it, not noone else can. WONTFIX only means WONTFIX if that's in the one true source of the project, i.e. upstream.
RH usually have a lot of not-upstream patches though (at least they do for the kernel, grub, and qemu, so I assume the same for libvirt) which complicates things a bit.