I agree it needs to catch the stable tag. If it affects only VS
builds then I am not going to insist on extending the hard freeze,
but I (technically on holiday today/tomorrow) don't have time to
dig much deeper into it.

[Liming] This fix is to restore the original behavior before the
commit 818283de3f6d for !INCLUDE style in Makefile generation. It does
update GNUmakefile and VS makefile generation. Because it just
restores original behavior, its quality risk is low. So, I suggest to catch it in this stable tag on current release planning.

However, I think the process is pretty clear that this *should*
extend the hard freeze.

[Liming] I am not aware of the process to extend the hard freeze. But,
you think more time is required for the review and test on the critical bug fix. I am OK.

I will note that from the trail (commitdate of 818283de3f6d until
BZ2563 was raised) it appears that detecting this bug itself,
which went in two days before the soft freeze, took 15 days.

[Liming] Yes. It takes 15 days to expose this issue.

I agree with Liming's analysis on the patches (i.e., what goes in
and what gets postponed), and I agree with Leif that we should
extend the hard freeze by at least a couple of days.

[Liming] If you both agree to extend the hard freeze, I have no objection.
I request to extend few days instead of few weeks if no other critical issues are reported.
Then, the impact of the community can be reduced.

This is not unusual. Originally I thought that edk2 freeze and
release dates were set in stone, but then Mike explained to me that
that had never been the intent. And other open source projects do
several pre-releases (rc0, rc1, .... pre-releases with "release
critical" (rc) bug fixes), before a final release. For example, QEMU
regularly plans
rc0..rc2 or even rc3, and then *optionally* adds an rc4 if even rc3
receives significant bugfixes. The idea is that the final release /
tag should be preceded by a silent / calm period, where we've waited
a few days and become reasonably convinced that "OK, there's nothing
else we should obviously fix right now".

I wouldn't immediately suggest a full week extension, but maybe
until March 4th (middle of next week)?

[Liming] March 4th is one good choice to reserve few days for the different time zone people.
If no more feedback, I will send announcement to delay this stable tag on Feb 28th (00:00:00 UTC-8).