From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 70BB921959CB2 for ; Wed, 15 Aug 2018 04:13:37 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9BB4C4077B97; Wed, 15 Aug 2018 11:13:36 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-100.rdu2.redhat.com [10.10.120.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8BCBA7C58; Wed, 15 Aug 2018 11:13:35 +0000 (UTC) To: "Zhang, Chao B" , "Kinney, Michael D" , "edk2-devel@lists.01.org" , "leif.lindholm@linaro.org" , "Andrew Fish (afish@apple.com)" , "Richardson, Brian" References: <84fd5fe6-0c94-393d-313c-5ae8ca3f088c@redhat.com> From: Laszlo Ersek Message-ID: Date: Wed, 15 Aug 2018 13:13:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 15 Aug 2018 11:13:36 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 15 Aug 2018 11:13:36 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: EDK II Stable Tag release edk2-stable201808 and quiet period starting today X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 11:13:37 -0000 Content-Type: text/plain; charset=iso-2022-jp Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/15/18 04:05, Zhang, Chao B wrote: > Hi Laszlo > 8 667abfaf8a16 UefiCpuPkg: Removing ipf which is no longer supported from edk2. > 9 df49a85dbcc6 CorebootModulePkg: Removing ipf from edk2. > 10 04c7f9023ffe CorebootPayloadPkg: Removing ipf from edk2. > 11 4fcb0d54584f NetworkPkg: Removing ipf which is no longer supported from edk2. > 12 87f9867f5536 QuarkPlatformPkg: Removing ipf which is no longer supported from edk2. > 13 fda6abd64f02 QuarkSocPkg: Removing ipf which is no longer supported from edk2. > 14 22ec06c8aaa1 Vlv2TbltDevicePkg: Removing ipf which from edk2. > > These patches are in a patch series to remove IPF. The community > review has been started a very long time before silent period. And > part of patch series was already in EDK2. > There is no source code change but only removes some useless sections > in INF & DSC. And from feature complete perspective, I think it is OK > to check-in. > Anyway, We will learn from this process and be more careful. We should distinguish two things here. - The first is the scope of the quiet period. That is, what kinds of commits are permitted, for what packages. - The second is whether (and how) we honor the quiet period. My email was about the 2nd point; that is, that we should respect the quiet period, with whatever scope that had been set. The scope was set by Mike's earlier announcement (1st point), and it said "critical issues only" and "bugzillas required". I'm fine with updating the scope, even during the quiet period, but it should be a discussion. Most other open source projects do something similar; for example they tag release candidates (RCs) before an actual release, and they keep iterating release candidates until all known regressions or critical bugs are fixed. Sometimes they might even postpone a release (and then the tag name could be necessary to update) -- such projects say, "it's done when it's done, and not when a specific date arrives". In the QEMU project there are two kinds of "freezes", for entering the quiet period. https://wiki.qemu.org/Planning/SoftFeatureFreeze https://wiki.qemu.org/Planning/HardFeatureFreeze * Using that terminology, and considering the quiet period announcement from 8 Aug a "soft freeze", merging the remaining IPF removal patches would have been fine, between the soft freeze and the hard freeze, because the patches had been posted and reviewed before the soft freeze. On the other hand, Mike's series "[edk2] [Patch 0/4] Vlv2TbltDevicePkg: Add FmpDevicePkg support" wouldn't qualify, because it was posted on 10 Aug (the quiet period, now interpreted as "soft freeze", was announced on 8 Aug). * Alternatively, considering the quiet period announcement from 8 Aug a "hard freeze", neither patch set should have been pushed, because none of them are bug fixes. Personally I took the announcement as a "hard freeze", because it said "critical bug fixes only". Again, if we'd really like to complete some pending features before tagging a commit as "stable", I'm fine if we move out the tag a few weeks. The point is, once we determine a scope, we should stick to it; and if modifications are necessary, discuss them on the list (or in BZs). Otherwise different maintainers will gate commits against different criteria. Another thing I believe QEMU does well is a "planning" wiki page, for the next release. This helps developers keep the scope up-to-date, and compare feature / bugfix status (e.g. list of BZs) against the most recently set release date. https://wiki.qemu.org/Planning/3.0 Thanks Laszlo