Re: [urgent] Soft Feature Freeze has started since Nov.1 for dk2-stable201811

[Laszlo Ersek <lersek@redhat.com>]

On 11/09/18 20:08, Phil Dennis-Jordan wrote:
> Hi Laszlo,
> 
> On Fri, Nov 9, 2018 at 5:47 PM Laszlo Ersek <lersek@redhat.com> 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
>> <https://www.qemu.org/> 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 <https://bugzilla.tianocore.org/show_bug.cgi?id=1319>
now, and I'll soon post the revert-revert series.

Thanks!
Laszlo