[edk2-devel] Patch List for 202002 stable tag
Laszlo Ersek
lersek at redhat.com
Tue Mar 3 11:37:17 UTC 2020
On 03/03/20 09:29, Gao, Liming wrote:
> 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
(1) Side request: please don't mix up the term "submit" with "push" or
"merge". Submit means submitting for review. "Push" or "merge" means the
patch is part of the git history.
I don't know where this mis-use of the term "submit" comes from. I've
noticed it only recently, on the list, and maybe in a few BZ comments.
It's very confusing.
(2) Actual request: TianoCore#2556 is still in UNCONFIRMED state. Just
about every aspect of that ticket is wrong:
- wrong status (should be resolved|fixed)
- wrong assignee (should be Leo, not Mike)
- the posted patch has not been referenced in a comment (into the list
archive)
- the commit hash of the resultant commit has not been noted in the BZ
(in a comment).
- the underlying issue seems like a regression on AMD platforms, from
the patch that introduced the PlatformId check. The Keywords field
should have "regression" selected, and a comment should explain what
commit exactly introduced the regression (the PlatformId check).
Leo: please fix up those problems in the BZ ticket urgently.
>
> 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
Not submitted, merged.
Otherwise, OK.
>
> 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.
OK.
Maciej: if you really think this BZ (#2032) should not be in the scope
of CVE-2019-14559, then please go to
<https://bugzilla.tianocore.org/show_bug.cgi?id=2032>, and remove "2550"
from the "Blocks" field, after clicking "edit".
Thanks
Laszlo
>
> Thanks
> Liming
> -----Original Message-----
> From: devel at edk2.groups.io <devel at edk2.groups.io> On Behalf Of Leif Lindholm
> Sent: 2020年2月28日 20:48
> To: Gao, Liming <liming.gao at intel.com>
> Cc: Laszlo Ersek <lersek at redhat.com>; devel at edk2.groups.io; Kinney, Michael D <michael.d.kinney at intel.com>; afish at apple.com; Guptha, Soumya K <soumya.k.guptha at intel.com>; Marvin Häuser <marvin.haeuser at outlook.com>; Gao, Zhichao <zhichao.gao at intel.com>; 'ard.biesheuvel at linaro.org' <ard.biesheuvel at linaro.org>; Wu, Hao A <hao.a.wu at intel.com>; vit9696 <vit9696 at protonmail.com>; gaurav.jain at nxp.com; Ni, Ray <ray.ni at intel.com>; Feng, Bob C <bob.c.feng at intel.com>; maciej.rabeda at linux.intel.com; leo.duran at 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 (#55316): https://edk2.groups.io/g/devel/message/55316
Mute This Topic: https://groups.io/mt/71371549/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list