Re: Patch List for 202002 stable tag

Liming Gao

Hi, Stewards and all:
Below three patches status are updated. If you have no other comments, I will create edk2-stable202002 tomorrow and send the announcement. [PATCH 0/2] UefiCpuPkg/Library: Fix bug in MpInitLib (BZ: 2556)
[Liming 2020-02-28] The solution is under discussion. The submitter requests this issue to be fixed happen reasonably soon. So, it may not catch this stable tag.
[Liming 2020-03-03] The solution is finalized. The patch passed reviewed. Now, it can catch this stable tag stable202002. The package maintainer submitted it in edk2 master 4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70. PR: [Patch 1/1][edk2-stable202002]BaseTools: Fixed a regression issue in Makefile for incremental build (BZ: 2563)
[Liming 2020-02-28] This patch has passed review. This regression causes the basic incremental build not work with VS nmake tool. The fix is clear. So, it need to catch this stable tag.
[Liming 2020-03-03] It is regarded as the critical fix. It was submitted in edk2 master at 2be4828af1c92a848af90429a9a0b44544c80553. PR: [PATCH v1] ShellPkg: Fix 'ping' command Ip4 receive flow. (BZ: 2032)
[Liming 2020-02-28] This is the issue in ShellPkg. It may not be critical issue, and defer after this stable tag.
[Liming 2020-03-03] The submitted advised moving this issue out of CVE scope (and from stable-202002). So, it will defer after this stable tag.


-----Original Message-----
From: <> On Behalf Of Leif Lindholm
Sent: 2020年2月28日 20:48
To: Gao, Liming <liming.gao@...>
Cc: Laszlo Ersek <lersek@...>;; Kinney, Michael D <michael.d.kinney@...>; afish@...; Guptha, Soumya K <soumya.k.guptha@...>; Marvin Häuser <marvin.haeuser@...>; Gao, Zhichao <zhichao.gao@...>; 'ard.biesheuvel@...' <ard.biesheuvel@...>; Wu, Hao A <hao.a.wu@...>; vit9696 <vit9696@...>; gaurav.jain@...; Ni, Ray <>; Feng, Bob C <bob.c.feng@...>; maciej.rabeda@...; leo.duran@...
Subject: Re: [edk2-devel] Patch List for 202002 stable tag

On Fri, Feb 28, 2020 at 04:13:09 +0000, Gao, Liming wrote:
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.
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 the original.

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).
I am OK with March 4th.



Join { to automatically receive all group messages.