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.
https://edk2.groups.io/g/devel/message/55105 [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: https://github.com/tianocore/edk2/pull/410 https://edk2.groups.io/g/devel/message/54992 [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: https://github.com/tianocore/edk2/pull/409 https://edk2.groups.io/g/devel/message/54995 [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. Thanks Liming -----Original Message----- From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Leif Lindholm Sent: 2020年2月28日 20:48 To: Gao, Liming <liming....@intel.com> Cc: Laszlo Ersek <ler...@redhat.com>; devel@edk2.groups.io; Kinney, Michael D <michael.d.kin...@intel.com>; af...@apple.com; Guptha, Soumya K <soumya.k.gup...@intel.com>; Marvin Häuser <marvin.haeu...@outlook.com>; Gao, Zhichao <zhichao....@intel.com>; 'ard.biesheu...@linaro.org' <ard.biesheu...@linaro.org>; Wu, Hao A <hao.a...@intel.com>; vit9696 <vit9...@protonmail.com>; gaurav.j...@nxp.com; Ni, Ray <ray...@intel.com>; Feng, Bob C <bob.c.f...@intel.com>; maciej.rab...@linux.intel.com; leo.du...@amd.com 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. Thanks! / Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#55293): https://edk2.groups.io/g/devel/message/55293 Mute This Topic: https://groups.io/mt/71371549/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
