From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web12.7470.1582824321663130006 for ; Thu, 27 Feb 2020 09:25:21 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CIcfkqYU; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582824320; 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=OaUXWXAYELNkxO69iydiN/Ls4U74XfpKp71PRUdh8Qw=; b=CIcfkqYULEl4uVk/uq43939Pkxh3tfBVezz7FrQo+cLS9gF0yDc2Zb4umFd/1q+BpBFqBF nDw288LnWYK7zyZNNKULrtHrZ3KE7m3AqMHOTW+TgQLRkPLNts30q2s3Ots3VGBKz+ECB+ KQZMGlIoo6VGQ9PYau0QfHH3ERQjYeg= 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-410-hRHV-gMkM5O7KwR3XYhkFw-1; Thu, 27 Feb 2020 12:25:11 -0500 X-MC-Unique: hRHV-gMkM5O7KwR3XYhkFw-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 8E8948017CC; Thu, 27 Feb 2020 17:25:09 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id 050325DA7C; Thu, 27 Feb 2020 17:25:05 +0000 (UTC) Subject: Re: [edk2-devel] Patch List for 202002 stable tag To: Leif Lindholm , devel@edk2.groups.io, liming.gao@intel.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" , "maciej.rabeda@linux.intel.com" , "leo.duran@amd.com" References: <7f58502307c643999e73ee73673f5fae@intel.com> <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> From: "Laszlo Ersek" Message-ID: <51eae9d3-b891-2685-186b-023a82bdebcc@redhat.com> Date: Thu, 27 Feb 2020 18:25:05 +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: <20200227162318.GC23627@bivouac.eciton.net> 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 02/27/20 17:23, Leif Lindholm wrote: > Hi Liming, >=20 > On Thu, Feb 27, 2020 at 16:06:22 +0000, Liming Gao wrote: >> Stewards: >> I update the patch lists and status. Based on current information, >> only one patch (item 5) needs catch this stable tag. Its fix is >> clear, and risk is low. So, I think we can still keep current >> planning to create stable tag edk2-stable202002 on 2020 Feb 28th >> (UTC =E2=80=93 8). If you think the stable tag needs to be delay for f= ew >> days, please reply the mail before Feb 28th (00:00:00 UTC-8). >> >> 1. https://edk2.groups.io/g/devel/message/54665 [edk2-devel] [PATCH v= 2 1/1] EmbeddedPkg: Fixed Asserts in SCT Runtime Services test. >> [Liming] This patch is still under review. So, it will not catch this st= able tag. >> >> 1. https://edk2.groups.io/g/devel/message/54693 [edk2-stable202002][e= dk2-devel] [PATCH v2 1/1] MdeModulePkg/Pci: Fixed Asserts in SCT PCIIO Prot= ocol Test. >=20 > Unrelated to the release process, only the formatting: > It looks like you are doing ordered lists using markdown syntax > (1.). This renders in plain text email simply as all items being 1. >=20 >> [Liming] The patch has passed review. Package maintainer thinks this is = an enhancement. It will be added after stable tag. >> >> 1. https://edk2.groups.io/g/devel/message/54122 [PATCH 1/1] ShellPkg:= Add support for input with separately reported modifiers >> [Liming] The discussion shows this change needs UEFI spec clarification.= So, it may not be resolved in short team. It will not catch this stable ta= g. The discussion is in BZ 2510. >> >> 1. https://edk2.groups.io/g/devel/message/54797 [PATCH 0/2] UefiCpuPk= g/Library: Fix bug in MpInitLib >> [Liming] The solution is under discussion (BZ 2556). The submitter reque= sts this issue to be fixed happen reasonably soon. So, it may not catch thi= s stable tag. >> >> 1. https://edk2.groups.io/g/devel/message/54992 [Patch 1/1][edk2-stab= le202002]BaseTools: Fixed a regression issue in Makefile for incremental bu= ild >> [Liming] This patch has passed review. This regression causes the basic = incremental build not work with VS nmake tool. The fix is clear. So, it nee= d to catch this stable tag. >=20 > 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. >=20 > However, I think the process is pretty clear that this *should* extend > the hard freeze. >=20 > 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. 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. 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)? Thanks Laszlo