[PATCH for-5.0 3/4] Remove the core bluetooth code

Aleksandar Markovic aleksandar.m.mail at gmail.com
Wed Feb 5 18:03:05 UTC 2020


> 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 :|
>





More information about the libvir-list mailing list