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

[Philippe Mathieu-Daudé]

On 2/5/20 6:51 PM, Daniel P. Berrangé wrote:
> 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é <address@hidden> 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 understand your point when looking forward (when distribution upgrade,
it is easy to adapt).
However this is still an issue when looking backward when running
bisection to find regressions.

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