On 21 October 2016 at 21:40, Laszlo Ersek <ler...@redhat.com> wrote: > On 10/21/16 22:19, Ard Biesheuvel wrote: >> On 21 October 2016 at 21:14, Laszlo Ersek <ler...@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? ;) >
Yes it is. But it should be made explicit. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
