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

[Andrew Fish <afish@apple.com>]

> On Oct 21, 2016, at 1:54 PM, Andrew Fish <afish@apple.com> wrote:
> 
>> 
>> On Oct 21, 2016, at 1:39 PM, Jordan Justen <jordan.l.justen@intel.com> wrote:
>> 
>> On 2016-10-21 13:20:49, Andrew Fish wrote:
>>>    On Oct 21, 2016, at 12:58 PM, Jordan Justen <jordan.l.justen@intel.com>
>>>    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.
>>> 
>>>  Jordan,
>>>  I think it depends on your point of view. If you have a platform that
>>>  works and you update the edk2 revision you would expect it to still work.
>> 
>> I think this is what UDK is for. If you want to depend directly on EDK
>> II, then you'll see less stability.
>> 
> 
> Jordan,
> 
> Well there should be a published plan for a future UDK that this change is going to happen before we "break it" in master. Publishing the plan with the UDK does not count :). 
> 
>>>  Thus the option is to DISABLE_DEPRECATED_INTERFACES as that maintains
>>>  backward compatibility.
>> 
>> In order to support UDK releases, maybe ENABLE_UDK2014_INTERFACES would be
>> something to consider. Or ENABLE_UDK_INTERFACE=2014 so we can use <=.
>> 
>> But, I still think that EDK II platforms (as a goal) should represent
>> the best, cleanest examples of using EDK II. And, I think having every
>> platform accumulate cruft like CFLAGS to disable deprecated interfaces
>> works against that goal.
>> 
>> Another point. What about when we want to deprecate more interfaces?
>> Oh know, we better not break platforms that only specified
>> DISABLE_NEW_DEPRECATED_INTERFACES! Let's add
>> DISABLE_NEW_DEPRECATED_INTERFACES2! :)
>> 
> 
> I think you make a very good point. How about DISABLE_2014_DEPRECATE_INTERFACES. I think that version scales, and might actually encourage cleanup as it shows when the interface first got deprecated. 
> 

Sorry, DISABLE_2014_DEPRECATED_INTERFACES.

Thanks,

Andrew Fish

> Thanks,
> 
> Andrew Fish
> 
>> -Jordan
>> 
>>>  I think it makes total sense to turn on DISABLE_DEPRECATED_INTERFACES on
>>>  all the open source edk2 platform as soon as possible so all the open
>>>  source code is following current best practices.
>>>  Not to mention it would probably be a really good idea to give all the
>>>  downstream folks a long lead time about the plan of making a non backward
>>>  compatible change. 
>>>  Thanks,
>>>  Andrew Fish
>>> 
>>>    -Jordan
>>> 
>>>      Before making any such changes, I would like a strong commitment from
>>>      other package owners that deprecating an interface brings along with
>>>      it the responsibility to update all existing callers, otherwise
>>>      setting this define will only result in more breakage, and ARM has
>>>      seen its share of inadvertent breakage in the past when changes to
>>>      core code were made without taking other architectures into account.
>>> 
>>>      On 21 October 2016 at 02:21,  <bugzilla-daemon@bugzilla.tianocore.org>
>>>      wrote:
>>> 
>>>        https://bugzilla.tianocore.org/show_bug.cgi?id=164
>>> 
>>>        yonghong.zhu@intel.com changed:
>>> 
>>>                  What    |Removed                     |Added
>>>        ----------------------------------------------------------------------------
>>>                  Priority|Lowest                      |Normal
>>>                    Status|UNCONFIRMED                 |CONFIRMED
>>>                  Assignee|michael.d.kinney@intel.com
>>>         |ard.biesheuvel@linaro.org
>>>            Ever confirmed|0                           |1
>>>            Release(s) the|                            |EDK II Trunk
>>>            issues must be|                            |
>>>                     fixed|                            |
>>> 
>>>        --- Comment #1 from yonghong.zhu@intel.com ---
>>>        Assign to Package owner.
>>> 
>>>        --
>>>        You are receiving this mail because:
>>>        You are the assignee for the bug.
>>> 
>>>      _______________________________________________
>>>      edk2-devel mailing list
>>>      edk2-devel@lists.01.org
>>>      https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel> <https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> <mailto:edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>>
>> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel> <https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel <https://lists.01.org/mailman/listinfo/edk2-devel>