Hacker News new | ask | show | jobs
by rwmj 1050 days ago
It's a bug filed against RHEL 7 originally, by someone working at Red Hat, who suggested that we add the qemu disable-io feature to libvirt. There was no customer case behind either the original RHEL 7 bug nor this cloned RHEL 8 bug, so we simply didn't think it was important to implement this, and 5 years after the original bug was filed, with no customer coming along nor anyone having done the work upstream, the bug was auto-closed.

However if someone came along and did the work upstream to fix it, I'm sure that would be accepted.

Or if a customer turned up who wanted this, that would also be implemented.

1 comments

WONTFIX sounds so final.

Though, reading the closing comment, this is really CLOSED-WONTFIXYET, as in no plans.

Maybe it'd be nice to introduce a WONTFIXYET. Might be useful to fossick among features abandoned that someday become feasible.

Yeah WONTFIX implies will not accept patches in every project I've worked on.
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.

We usually use "Open, P4" (0 is highest. 2 is standard) for unscheduled work.
Some people strongly dislike "open" for anything not being worked on or having plans to work on. And I've come to agree to that. You just do not want it showing up in backlogs at all.