> On Oct 21, 2016, at 1:54 PM, Andrew Fish <[email protected]> wrote: > >> >> On Oct 21, 2016, at 1:39 PM, Jordan Justen <[email protected]> wrote: >> >> On 2016-10-21 13:20:49, Andrew Fish wrote: >>> On Oct 21, 2016, at 12:58 PM, Jordan Justen <[email protected]> >>> 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, <[email protected]> >>> wrote: >>> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=164 >>> >>> [email protected] changed: >>> >>> What |Removed |Added >>> >>> ---------------------------------------------------------------------------- >>> Priority|Lowest |Normal >>> Status|UNCONFIRMED |CONFIRMED >>> Assignee|[email protected] >>> |[email protected] >>> Ever confirmed|0 |1 >>> Release(s) the| |EDK II Trunk >>> issues must be| | >>> fixed| | >>> >>> --- Comment #1 from [email protected] --- >>> Assign to Package owner. >>> >>> -- >>> You are receiving this mail because: >>> You are the assignee for the bug. >>> >>> _______________________________________________ >>> edk2-devel mailing list >>> [email protected] >>> 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 >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> 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 > [email protected] <mailto:[email protected]> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
