回复: [edk2-devel] feature flag change notifications

["gaoliming" <gaoliming@byosoft.com.cn>]

Dann:
  I base on new features to collect the incompatible changes, and add them into the updated notes. 

  If you find any missing, please send the mail to me. 

Thanks
Liming
> -----邮件原件-----
> 发件人: Kinney, Michael D <michael.d.kinney@intel.com>
> 发送时间: 2022年12月6日 9:22
> 收件人: devel@edk2.groups.io; dann.frazier@canonical.com; Gao, Liming
> <gaoliming@byosoft.com.cn>
> 主题: RE: [edk2-devel] feature flag change notifications
> 
> Hi Dann,
> 
> These are reasonable requests.
> 
> Adding Liming Gao who is currently responsible for the edk2 releases.
> 
> Let's start with release notes and see if some of these can be added
> to the release documentation and add to the edk2 release process
> to clearly note these type of changes in future release notes.
> 
> As far as #error and #warn.  Those are possible, but we would need
> to do some analysis for the types of changes that would require
> that behavior.  Your examples are useful as a starting point.
> 
> Once concern is how many of those #error/#warn conditions will
> build up over time and then a process to remove them after an
> expiration period.
> 
> Mike
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of dann
> frazier
> > Sent: Monday, December 5, 2022 4:10 PM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] feature flag change notifications
> >
> > Hi,
> >   I maintain the edk2 packages in the Debian and Ubuntu
> > distributions. A few times over the years I've had users report
> > regressions that turned out to be due to upstream build flag
> > changes. I wonder if it would be possible for upstream to communicate
> > such changes - either via release notes or, where possible, as
> > build-time checks - to us downstream projects. Here are the examples I
> > recall:
> >
> > > commit 4de8d61bcec02a13ceed84f92b0cf3ea58adf9c5
> > > Author: Gerd Hoffmann <kraxel@redhat.com>
> > > Date:   Wed Dec 15 12:39:20 2021 +0100
> > >
> > >     OvmfPkg: rework TPM configuration
> > >
> >
> > For this I needed to change -DTPM_ENABLE=TRUE to
> -DTPM2_ENABLE=TRUE. I
> > feel like a build-time check would've been a good way to communicate
> > this one, e.g.:
> >
> > #ifdef TPM_ENABLE
> > #error TPM_ENABLE has been renamed to TPM2_ENABLE
> > #endif
> >
> > > commit 1631bb26ae991e530d3c96fe3161ea15144b358e
> > > Author: Gary Lin <glin@suse.com>
> > > Date:   Mon Jun 10 14:55:09 2019 +0800
> > >
> > >     OvmfPkg/README: Update the network build flags
> > >
> > >     The following network build flags changed due to the inclusion of
> > >     NetworkPkg/Network.fdf.inc.
> > >
> > Similar to the above, I needed to deal with this by setting
> > -DNETWORK_HTTP_BOOT_ENABLE=TRUE instead of
> -DHTTP_BOOT_ENABLE=TRUE. It
> > seems like maybe an #error on the removed #define could've helped
> > here as well.
> >
> > And finally:
> >
> > > commit 57783adfb579da32b1eeda77b2bec028a5e0b7b3
> > > Author: Michael D Kinney <michael.d.kinney@intel.com>
> > > Date:   Tue Jul 26 12:40:00 2022 -0700
> > >
> > >     OvmfPkg: Change default to disable MptScsi and PvScsi
> >
> > With this types of change, it would be useful just to know this is
> > coming and why so I can decide to either notify users of the change
> > and/or override the default to avoid the regression. Would it be
> > possible to describe such changes in the release notes at
> > https://github.com/tianocore/edk2/releases - and, if not urgent,
> > perhaps #warn of deprecation in the source for one stable release
> > cycle?
> >
> >   -dann
> >
> >
> > 
> >