(Cc'ing migration compat and libvirt teams)
On 28/10/26 02:01, Richard Henderson wrote:
On 10/27/26 14:23, Philippe Mathieu-Daudé wrote:
'debug-threads' option for -name was deprecated in v11.0
(commit 1b65aeed2a0 "system: unconditionally enable thread
naming") thus can now be removed.
Signed-off-by: Philippe Mathieu-Daudé<[email protected]>
Reviewed-by: Pierrick Bouvier<[email protected]>
Reviewed-by: Ján Tomko<[email protected]>
Reviewed-by: Dr. David Alan Gilbert<[email protected]>
Message-Id:<[email protected]>
---
docs/about/deprecated.rst | 7 -------
docs/about/removed-features.rst | 9 +++++++--
system/vl.c | 11 -----------
tests/qtest/migration/framework.c | 4 ++--
tests/qtest/migration/precopy-tests.c | 2 +-
qemu-options.hx | 7 +++----
6 files changed, 13 insertions(+), 27 deletions(-)
You need to remove this from the testsuite as well:
https://gitlab.com/qemu-project/qemu/-/jobs/17523155796#L58
Hmm I was surprised because the pipeline in my fork passed, but then
looking clearer this job is marked as "allow_failure: true" for me,
why is it blocking on the mainstream repo?
Back to the test, this is the migration-compat-x86_64 job running
previous release binary vs latest one, so I'd think this is the
expected behavior, v11.0 and v11.1 have that deprecated option, and
we can not test vs v11.2 which removed it.
If we want to change that workflow, then when deprecating on v11.0
we also need to remove the tests coverage, so when we remove the
feature at $deprecation_release+2 the migration-compat test does not
break. Here the question is, do we want to keep testing deprecated
features? Maybe yes in the case of unmaintained area when the
deprecation process triggers new maintainers stepping in and the
deprecation to be cancelled.
We could also mark the feature removed but keep it ignored and
undocumented until the next release but we'll likely forget and
miss that in workflow so I don't recommend that way.
Maybe there are another ways to resolve that but I'm not seeing
them. Ideas?
