Re: [edk2-devel] feature flag change notifications

["dann frazier" <dann.frazier@canonical.com>]

Hi Liming,

  Thank you, that is appreciated. Going forward I'll let you know if I
trip over any not already documented.

  -dann

On Tue, Dec 6, 2022 at 5:59 PM gaoliming via groups.io
<gaoliming=byosoft.com.cn@groups.io> wrote:
>
> 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
> > >
> > >
> > >
> > >
>
>
>
>
>
> 
>
>