Re: [PATCH for-5.0 3/4] Remove the core bluetooth code
The deprecation policy is primarily intended for notifying of
changes
to QEMU's stable interfaces ( CLI, HMP, QMP) which affect behaviour
and usage of QEMU at runtime & are liable to break apps managing
QEMU.
Changes to build time options have no strong reason to be subjected to
the deprecation process.
This sounds reasonable to me.
But: Should our deprecation policy be clearer on what is subject to
our deprecation procedure, and what is not?
Regards,
Aleksandar
If we remove an option at build time the effect
is noticed immediately and the solution is straightforward (stop passing
the option). We have added / removed configure options at will with little
negative feedback historically. We'll have far biggest changes coming to
the build system in future too, with the introduction of meson.
I don't think we want to constrain & complicate our work in modernizing
the build system by declaring that any changes to it must go through
deprecation.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|