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

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

On Wed, Feb 05, 2020 at 06:40:31PM +0100, Aleksandar Markovic wrote:
> On Sat, Feb 1, 2020 at 7:53 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >
> > > >> @@ -1151,10 +1150,6 @@ for opt do
> > > >>    ;;
> > > >>    --enable-brlapi) brlapi="yes"
> > > >>    ;;
> > > >> -  --disable-bluez) bluez="no"
> > > >> -  ;;
> > > >> -  --enable-bluez) bluez="yes"
> > > >> -  ;;
> > > >
> > > > Now than I'm bisecting over this commit, I realize removing this
> > > > option was not a good idea, we should have done like commit
> > > > cb6414dfec8 or 315d3184525:
> > > >
> > > >   @@ -886,10 +885,6 @@ for opt do
> > > >   -  --disable-uuid) uuid="no"
> > > >   -  ;;
> > > >   -  --enable-uuid) uuid="yes"
> > > >   -  ;;
> > > >   ...
> > > >   +  --enable-uuid|--disable-uuid)
> > > >   +      echo "$0: $opt is obsolete, UUID support is always built" >&2
> > > >   +  ;;
> > >
> > > Looks trivial ... so if it bugs you, just send a patch?
> >
> > I thought about it but this won't fix much, it is too late now.
> >
> > I simply wanted to share this bugged me so we try to avoid doing the
> > same mistake again.
> >
> 
> I vote for addition of a change similar to what Philippe described.
> 
> Furthermore, it looks to me the correct way would be to now do full
> deprecation of --enable-bluez and --disable-bluez. This means adding
> this to documentation (not related to bluetooth devices support), not
> only a change in "configure". This also means that only after two next
> full cycles these options could be removed.
> 
> True, this could have been done together with bluetooth devices
> support deprecation (and in that case we could have deleted these
> options right away), but it wasn't. Users don't have a crystal ball to
> know that we assumed that --enable-bluez and --disable-bluez were part
> of bluetooth devices support, and could rightfully complain about an
> abrupt elimination of a compile time option.

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