On Wed, Oct 28, 2026 at 09:47:43AM +0000, Daniel P. Berrangé wrote:
> On Wed, Oct 28, 2026 at 08:32:20AM +0100, Philippe Mathieu-Daudé wrote:
> > (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?
>
> It isn't blocking on upstream repo, it is allow_failure: true there
> too. Manual inspection of the job shows it is a real bug though.
>
> > 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?
>
> 'debug-threads=on' has no relationship to live migration data
> stream, it merely gives the threads names. Just remove this
> option from the migration testsuite as it is irrelevant to
> what is being tested.
We're testing with the old migration-test for compat, so Phil doesn't have
an easy way to remove that part:
.migration-compat-common:
...
# Use the migration-tests from the older QEMU tree. This avoids
# testing an old QEMU against new features/tests that it is not
# compatible with.
- cd build-previous
Intentional to avoid new things not working with old QEMU binaries, but
then this will be the case things break if we don't have protection of
2-release deprecation (where we could have removed the usage in test cases
2 releases in advance too when deprecating).
At least two options I see: (1) for this release, we lose compat
protection, we'll need to manually guard it, or (2) we provide some way to
script/patch on top of the build-previous/ build before it builds, in this
case we only need to remove the string in that test alone.
I prefer (2) but I'd apologize in advance I don't have almost any time
upstream before forum (replied this one only because I want to raise the
point of using old test, in case Fabiano's already in PTO), I'm not sure if
someone thinks it worthwhile.
Thanks,
--
Peter Xu
