Re: [PULL 51/59] system: Remove deprecated 'debug-threads' option for -name

["Daniel P. Berrangé" <berrange@redhat.com>]

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é<philmd@oss.qualcomm.com>
> > > Reviewed-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com>
> > > Reviewed-by: Ján Tomko<jtomko@redhat.com>
> > > Reviewed-by: Dr. David Alan Gilbert<dave@treblig.org>
> > > Message-Id:<20261018232917.7716-1-philmd@oss.qualcomm.com>
> > > ---
> > >   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.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|