From: "Liming Gao" <liming.gao@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"leif@nuviainc.com" <leif@nuviainc.com>
Cc: "Laszlo Ersek" <lersek@redhat.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
"afish@apple.com" <afish@apple.com>,
"Guptha, Soumya K" <soumya.k.guptha@intel.com>,
"Marvin Häuser" <marvin.haeuser@outlook.com>,
"Gao, Zhichao" <zhichao.gao@intel.com>,
"'ard.biesheuvel@linaro.org'" <ard.biesheuvel@linaro.org>,
"Wu, Hao A" <hao.a.wu@intel.com>,
vit9696 <vit9696@protonmail.com>,
"gaurav.jain@nxp.com" <gaurav.jain@nxp.com>,
"Ni, Ray" <ray.ni@intel.com>,
"Feng, Bob C" <bob.c.feng@intel.com>,
"maciej.rabeda@linux.intel.com" <maciej.rabeda@linux.intel.com>,
"leo.duran@amd.com" <leo.duran@amd.com>
Subject: Re: [edk2-devel] Patch List for 202002 stable tag
Date: Tue, 3 Mar 2020 08:29:01 +0000 [thread overview]
Message-ID: <9746f6ba6ccf4486a93638c5135f1303@intel.com> (raw)
In-Reply-To: <20200228124820.GE23627@bivouac.eciton.net>
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.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>; devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; afish@apple.com; Guptha, Soumya K <soumya.k.guptha@intel.com>; Marvin Häuser <marvin.haeuser@outlook.com>; Gao, Zhichao <zhichao.gao@intel.com>; 'ard.biesheuvel@linaro.org' <ard.biesheuvel@linaro.org>; Wu, Hao A <hao.a.wu@intel.com>; vit9696 <vit9696@protonmail.com>; gaurav.jain@nxp.com; Ni, Ray <ray.ni@intel.com>; Feng, Bob C <bob.c.feng@intel.com>; maciej.rabeda@linux.intel.com; leo.duran@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
next prev parent reply other threads:[~2020-03-03 8:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 14:08 Patch List for 202002 stable tag Liming Gao
2020-02-18 20:04 ` Laszlo Ersek
2020-02-18 20:42 ` Michael D Kinney
2020-02-19 8:53 ` Laszlo Ersek
2020-02-19 15:39 ` Liming Gao
2020-02-19 18:09 ` Vitaly Cheptsov
2020-02-20 1:17 ` Liming Gao
2020-02-20 1:35 ` Gao, Zhichao
2020-02-20 3:13 ` Ni, Ray
2020-02-20 6:58 ` Liming Gao
2020-02-20 7:07 ` Vitaly Cheptsov
[not found] ` <15F50A1858BD174A.18319@groups.io>
2020-02-21 8:22 ` [edk2-devel] " Liming Gao
[not found] ` <15F55D425BF8837D.15709@groups.io>
2020-02-27 16:06 ` Liming Gao
2020-02-27 16:23 ` Leif Lindholm
2020-02-27 17:25 ` Laszlo Ersek
2020-02-28 4:13 ` Liming Gao
2020-02-28 12:48 ` Leif Lindholm
2020-03-03 8:29 ` Liming Gao [this message]
2020-03-03 11:37 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9746f6ba6ccf4486a93638c5135f1303@intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox