Re: [Bug 164] Add the build option "/D DISABLE_NEW_DEPRECATED_INTERFACES" in package DSC files

[Laszlo Ersek <lersek@redhat.com>]

On 10/21/16 22:19, Ard Biesheuvel wrote:
> On 21 October 2016 at 21:14, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 10/21/16 21:58, Jordan Justen wrote:
>>> On 2016-10-21 12:37:21, Ard Biesheuvel wrote:
>>>> I don't remember seeing any discussion regarding
>>>> DISABLE_NEW_DEPRECATED_INTERFACES on the list, so I am a bit surprised
>>>> seeing these bugs being filed and assigned.
>>>>
>>>
>>> I agree.
>>>
>>> Also, the terminology seems confusing. 'new deprecated' seems like a
>>> contradiction. I guess it means 'newly deprecated', but that seems
>>> like a term that is quickly going to become obsolete. Soon there will
>>> be old deprecated items that are disabled with this switch.
>>> DISABLE_DEPRECATED_INTERFACES sounds better.
>>>
>>> But, shouldn't we have platforms opt-in to using the deprecated
>>> interfaces rather than adding DISABLE_NEW_DEPRECATED_INTERFACES to the
>>> build command line for every EDK II platform?
>>>
>>> Not using deprecated items should be the default for EDK II platforms.
>>> If a platform has to opt-in to the deprecated content in their .dsc,
>>> then it is obvious that they are relying on deprecated functionality.
>>>
>>> So, I guess I'd propose adding ENABLE_DEPRECATED_INTERFACES instead.
>>
>> I'm about to post a ~20-part series for OvmfPkg and ArmVirtPkg together
>> that solves these BZs. :/ The DISABLE_NEW_DEPRECATED_INTERFACES feature
>> test macro is already being used in three MdePkg library class header
>> files (and a number of library instances), so I thought it was a done deal.
>>
>> I don't want to stifle the discussion of course, but at this point I
>> think I will post the patches for review.
>>
> 
> Yes, please. Removing uses of deprecated interfaces is something we
> should do anyway. What we shouldn't do is configure our platforms in
> such a way that additional future deprecation automatically break the
> build, unless we have a strong commitment from the other package
> owners that they will ensure that this does not happen.
> 

Well, my expectation is that the onus of keeping the tree working is on
the patch submitter. Assume we adopt DISABLE_NEW_DEPRECATED_INTERFACES
now (weaning ourselves off the functions that are *currently* disabled
by the macro). Then whenever someone moves further functions under the
scope of the macro -- thereby possibly breaking platform code --, it's
going to be their responsibility to grep the tree for platform DSCs that
enable DISABLE_NEW_DEPRECATED_INTERFACES, and either test-build those
platforms reasonably extensively, or ask for help *in advance* (before
committing the patches).

For example, in the current work I'm about the post, I couldn't
build-test everything (no RVCT over here, for example :)) Also I don't
run Xen, so the Xen-related changes can't be functionally tested on my
side -- but, I do ask for help with testing those. Same goes for the
32-bit ARM changes (which, it turns out, Michael and myself managed to
fix separately, independently, and differently :))

It's okay to modify code one can't build or test himself/herself, but
then help should be asked for, and given too.

TL;DR: the strong commitment you speak about is the default for any open
source project, isn't it? ;)

Thanks
Laszlo