On Fri, Feb 28, 2020 at 04:13:09 +0000, Gao, Liming wrote:
[Liming] This fix is to restore the original behavior before the commit 818283de3f6d
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.
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.
If it is *just* a revert, then the risk is often low enough to not
slip the date. But I think, as you say, this is something that
restores original behaviour - but leaving the code different from
[Liming] I am not aware of the process to extend the hard freeze. But, you think more time is
However, I think the process is pretty clear that this *should* extend
the hard freeze.
required for the review and test on the critical bug fix. I am OK.
[Liming] Yes. It takes 15 days to expose this issue.
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.
I agree with Liming's analysis on the patches (i.e., what goes in and[Liming] If you both agree to extend the hard freeze, I have no objection.
what gets postponed), and I agree with Leif that we should extend the
hard freeze by at least a couple of days.
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[Liming] March 4th is one good choice to reserve few days for the different time zone people.
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)?
If no more feedback, I will send announcement to delay this stable tag on Feb 28th (00:00:00 UTC-8).
I am OK with March 4th.