From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 2DE6E2118EF5C for ; Fri, 9 Nov 2018 11:32:26 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 789473001FE4; Fri, 9 Nov 2018 19:32:25 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-126-98.rdu2.redhat.com [10.10.126.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id 74E5C5D736; Fri, 9 Nov 2018 19:32:22 +0000 (UTC) To: Phil Dennis-Jordan Cc: leif.lindholm@linaro.org, Phil Dennis-Jordan , edk2-devel-01 , liming.gao@intel.com, brian.richardson@intel.com, stephano.cetola@intel.com, michael.d.kinney@intel.com References: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3659AB@SHSMSX104.ccr.corp.intel.com> <20181107153829.juygpydwln2s5jkj@bivouac.eciton.net> <01176b5b-8826-2c82-beef-45250fd88bef@redhat.com> <8ff81475-1712-86b0-a96e-0f281bc4a734@redhat.com> From: Laszlo Ersek Message-ID: Date: Fri, 9 Nov 2018 20:32:20 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Fri, 09 Nov 2018 19:32:25 +0000 (UTC) Subject: Re: [urgent] Soft Feature Freeze has started since Nov.1 for dk2-stable201811 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 19:32:27 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 11/09/18 20:08, Phil Dennis-Jordan wrote: > Hi Laszlo, > > On Fri, Nov 9, 2018 at 5:47 PM Laszlo Ersek wrote: >> >> + Yuchenlin, + Gerd, + both Phils >> >> On 11/07/18 20:13, Laszlo Ersek wrote: >> >>>>> For example, I reviewed and pushed 4 patches yesterday (on 2018-Nov-06): >>>>> >>>>> 1 e038bde2679b Revert "OvmfPkg/QemuVideoDxe: list "UnalignedIoInternal.h" in the INF file" >>>>> 2 98856a724c2a Revert "OvmfPkg/QemuVideoDxe: VMWare SVGA device support" >>>>> 3 438ada5aa5a1 Revert "OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O." >>>>> 4 328409ce8de7 Revert "OvmfPkg: VMWare SVGA display device register definitions" >>>>> >>>>> which are the first four patches (out of five) from the following >>>>> series: >>>>> >>>>> [edk2] [PATCH v2 0/5] OvmfPkg: simply use the Bochs interface for vmsvga >>>>> >>>>> These reverts are arguably not bugfixes; they are preparation for >>>>> re-implementing a feature from scratch (the last patch in that series). >>>>> Thus, had I known we were already in the Soft Feature Freeze, I wouldn't >>>>> have pushed them, because the review was not complete before the soft >>>>> freeze start. >>>>> >>>>> But I had just returned from a week (or more) of PTO, there was no >>>>> announcement on the list yet, and I didn't remember the wiki page. >>>>> >>>>> (In the technical sense, the reverts are not disruptive, luckily; they >>>>> remove code that is dead anyway.) >> >> I've given this more thought. >> >> The reverts indeed remove dead code, but the code in question is dead >> *only* on QEMU v2.10+. On QEMU v2.9 and earlier, the code is not dead. >> >> (See the original discussion in the thread "[edk2] [PATCH] OvmfPkg: >> initialize bochs when initializing vmsvga".) >> >> This means that, with only the first four patches applied from the >> series (= the reverts), and with the fifth patch (= the clean >> re-implementation of the feature) postponed, people running >> edk2-stable201811 on *old* -- v2.9 or older -- QEMU, with VMW SVGA, will >> suffer a regression. >> >> So that leaves me with a question. Should I revert the first four >> patches now, for edk2-stable201811? (I.e., revert the reverts --> >> re-instate the incorrect VMW SVGA driver impl, that happens to work on >> v2.9 and earlier.) >> >> ... Note that upstream QEMU no longer supports (= maintains stable >> branches) for v2.9 and earlier releases. The QEMU homepage >> currently advertizes: >> - 3.1.0-rc0 >> - 3.0.0 >> - 2.12.1 >> - 2.11.2 >> >> Personally I'm leaning towards keeping the reverts for >> edk2-stable201811. (v2.9 is really old, and the VMW SVGA device model is >> virtually unused.) For my professional integrity though, I must ask this >> question publicly. > > I suspect the number of users relying on this feature is small, and I > have my doubts that this group are running an unpatched snapshot of > the master branch, let alone a stable OVMF release. But I don't have > data for this, only anecdotal evidence. I personally won't be losing > much sleep over it assuming we fix it for ~all versions of Qemu soon > after. Thanks Phil -- that sounds justified and (for me) convenient too. But, I want to be precise and correct about this. I didn't push the patches out of carelessness (I had returned from a stretch of PTO, and there hadn't been a timely announcement on edk2-devel about the soft freeze -- and I don't think I could be expected to remember the schedule wiki page from a distance of multiple months). But, *why* I messed up doesn't matter; only the fact that I did, does. So, I've filed now, and I'll soon post the revert-revert series. Thanks! Laszlo