> On Oct 21, 2016, at 1:39 PM, Jordan Justen <jordan.l.jus...@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.jus...@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. 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-dae...@bugzilla.tianocore.org> >> wrote: >> >> https://bugzilla.tianocore.org/show_bug.cgi?id=164 >> >> yonghong....@intel.com changed: >> >> What |Removed |Added >> >> ---------------------------------------------------------------------------- >> Priority|Lowest |Normal >> Status|UNCONFIRMED |CONFIRMED >> Assignee|michael.d.kin...@intel.com >> |ard.biesheu...@linaro.org >> Ever confirmed|0 |1 >> Release(s) the| |EDK II Trunk >> issues must be| | >> fixed| | >> >> --- Comment #1 from yonghong....@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> > _______________________________________________ > 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> _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
