From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web12.2424.1583235454004291566 for ; Tue, 03 Mar 2020 03:37:34 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OUXhbXB6; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583235453; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N60hZ+87ybLNhCdJfQrCgE3ZoRzzO6SaGmqALyqCmRI=; b=OUXhbXB6AL33hrbqM9jiJUkCL05v+G/Ytj37va0f/FOpSw7oQD+NgXvKM/n0U4/TMltrvD 2P5eKTqDg+uhOzAjGA34I89Q5LK9U1BlFB0jwIwQ+VIgKv/PA3qsNJiDbOQPEBBGkeJPgb /sOzg4feNMDGFKIv99zQhlqyxCDCVSM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-265-EwPuCOXaMsi5bkrI2KxH2A-1; Tue, 03 Mar 2020 06:37:25 -0500 X-MC-Unique: EwPuCOXaMsi5bkrI2KxH2A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A596C107ACC7; Tue, 3 Mar 2020 11:37:22 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-34.ams2.redhat.com [10.36.117.34]) by smtp.corp.redhat.com (Postfix) with ESMTP id D07505DA75; Tue, 3 Mar 2020 11:37:18 +0000 (UTC) Subject: Re: [edk2-devel] Patch List for 202002 stable tag To: "Gao, Liming" , "devel@edk2.groups.io" , "leif@nuviainc.com" , "maciej.rabeda@linux.intel.com" , "leo.duran@amd.com" Cc: "Kinney, Michael D" , "afish@apple.com" , "Guptha, Soumya K" , =?UTF-8?Q?Marvin_H=c3=a4user?= , "Gao, Zhichao" , "'ard.biesheuvel@linaro.org'" , "Wu, Hao A" , vit9696 , "gaurav.jain@nxp.com" , "Ni, Ray" , "Feng, Bob C" References: <21493dd751f34291a59874d55c34fd13@intel.com> <10a293f739eb428c9c022615eafb0398@intel.com> <734D49CCEBEEF84792F5B80ED585239D5C447005@SHSMSX104.ccr.corp.intel.com> <15F50A1858BD174A.18319@groups.io> <15F55D425BF8837D.15709@groups.io> <8adb33d816bf4f45abd6d831403e6d01@intel.com> <20200227162318.GC23627@bivouac.eciton.net> <51eae9d3-b891-2685-186b-023a82bdebcc@redhat.com> <20200228124820.GE23627@bivouac.eciton.net> <9746f6ba6ccf4486a93638c5135f1303@intel.com> From: "Laszlo Ersek" Message-ID: Date: Tue, 3 Mar 2020 12:37:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9746f6ba6ccf4486a93638c5135f1303@intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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.=20 >=20 > https://edk2.groups.io/g/devel/message/55105 [PATCH 0/2] UefiCpuPkg/Libr= ary: Fix bug in MpInitLib (BZ: 2556)=20 > [Liming 2020-02-28] The solution is under discussion. The submitter requ= ests this issue to be fixed happen reasonably soon. So, it may not catch th= is 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 su= bmitted it in edk2 master 4c0f6e349d32cf27a7104ddd3e729d6ebc88ea70. PR: htt= ps://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. >=20 > https://edk2.groups.io/g/devel/message/54992 [Patch 1/1][edk2-stable2020= 02]BaseTools: Fixed a regression issue in Makefile for incremental build (B= Z: 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://gi= thub.com/tianocore/edk2/pull/409 Not submitted, merged. Otherwise, OK. >=20 > https://edk2.groups.io/g/devel/message/54995 [PATCH v1] ShellPkg: Fix 'p= ing' command Ip4 receive flow. (BZ: 2032) > [Liming 2020-02-28] This is the issue in ShellPkg. It may not be critica= l issue, and defer after this stable tag. > [Liming 2020-03-03] The submitted advised moving this issue out of CVE s= cope (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 , and remove "2550" from the "Blocks" field, after clicking "edit". Thanks Laszlo >=20 > Thanks > Liming > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Leif Lind= holm > Sent: 2020=E5=B9=B42=E6=9C=8828=E6=97=A5 20:48 > To: Gao, Liming > Cc: Laszlo Ersek ; devel@edk2.groups.io; Kinney, Mich= ael D ; afish@apple.com; Guptha, Soumya K ; Marvin H=C3=A4user ; Ga= o, Zhichao ; 'ard.biesheuvel@linaro.org' ; Wu, Hao A ; vit9696 ; gaurav.jain@nxp.com; Ni, Ray ; Feng, Bob C ; maciej.rabeda@linux.intel.com; leo.duran@amd.com > Subject: Re: [edk2-devel] Patch List for 202002 stable tag >=20 > 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=20 >>>> builds then I am not going to insist on extending the hard freeze,=20 >>>> but I (technically on holiday today/tomorrow) don't have time to=20 >>>> dig much deeper into it. >>>> >> [Liming] This fix is to restore the original behavior before the=20 >> commit 818283de3f6d for !INCLUDE style in Makefile generation. It does= =20 >> update GNUmakefile and VS makefile generation. Because it just=20 >> restores original behavior, its quality risk is low. So, I suggest to c= atch it in this stable tag on current release planning. >=20 > 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. >=20 >>>> However, I think the process is pretty clear that this *should*=20 >>>> extend the hard freeze. >> >> [Liming] I am not aware of the process to extend the hard freeze. But,= =20 >> 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,=20 >>>> which went in two days before the soft freeze, took 15 days. >> >> [Liming] Yes. It takes 15 days to expose this issue.=20 >> >>> I agree with Liming's analysis on the patches (i.e., what goes in=20 >>> and what gets postponed), and I agree with Leif that we should=20 >>> extend the hard freeze by at least a couple of days. >> >> [Liming] If you both agree to extend the hard freeze, I have no objecti= on.=20 >> I request to extend few days instead of few weeks if no other critical = issues are reported.=20 >> Then, the impact of the community can be reduced.=20 >> >>> This is not unusual. Originally I thought that edk2 freeze and=20 >>> release dates were set in stone, but then Mike explained to me that=20 >>> that had never been the intent. And other open source projects do=20 >>> several pre-releases (rc0, rc1, .... pre-releases with "release=20 >>> critical" (rc) bug fixes), before a final release. For example, QEMU= =20 >>> regularly plans >>> rc0..rc2 or even rc3, and then *optionally* adds an rc4 if even rc3=20 >>> receives significant bugfixes. The idea is that the final release /=20 >>> tag should be preceded by a silent / calm period, where we've waited= =20 >>> a few days and become reasonably convinced that "OK, there's nothing= =20 >>> else we should obviously fix right now". >>> >>> I wouldn't immediately suggest a full week extension, but maybe=20 >>> until March 4th (middle of next week)? >> [Liming] March 4th is one good choice to reserve few days for the diffe= rent time zone people. >> If no more feedback, I will send announcement to delay this stable tag = on Feb 28th (00:00:00 UTC-8). >=20 > I am OK with March 4th. >=20 > Thanks! >=20 > / > Leif >=20 >=20 >=20