Re: [PATCH] Maintainers.txt: update OvmfPkg maintainership

[Laszlo Ersek <lersek@redhat.com>]

Hello Konrad,

On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 17, 2017 at 01:47:59AM +0200, Laszlo Ersek wrote:
>> On 08/17/17 00:37, Jordan Justen wrote:
>>> On 2017-08-16 12:23:49, Leif Lindholm wrote:
>>
>> [snip]
>>
>>>> - the value proposition
>>>> for Linaro is that having maintainer parity ArmVirtPkg/OvmfPkg
>>>> simplifies the task of maintaining feature parity between the two.
>>>> (It is no secret that I would love to see them as a single package,
>>>> making it easier to clean up the way EDK2-for-qemu gets packaged by
>>>> Linux distributions.)
>>>
>>> I would also prefer to have OVMF support ARM and eventually RISC-V as
>>> well. I don't think Laszlo feels as confident about this though.
>>
>> I have two concerns:
>>
>> (1) Reorganizing OvmfPkg for this would take an immense amount of time
>> (with possible regressions).
>>
>> (2) Sharing more code between modules that aren't inherently
>> architecture-independent (and virtualization platform-independent) is risky.
>>
>> By "sharing more code", I mean extracting further library classes and
>> then unifying originally separate drivers. I also mean extracting common
>> files from separate library instances, and then unifying the lib
>> instances in a common directory, with multiple INF files, or with
>> arch-dependent sections in the one resultant INF file. Another method is
>> to control the same set of drivers / library instances differently, via
>> dynamic PCDs.
>>
>> While all this is great for code de-duplication, the chance of
>> regressions skyrockets if the code de-dup is not matched by a similar
>> overlap in maintenance (that is, review and testing).
>>
>> Personally I use QEMU/KVM (and occasionally QEMU/TCG) on x86 and
>> aarch64. I don't use 32-bit ARM (even guests, on aarch64 hosts), or any
>> kind of Xen. I've never seen RISC-V hardware (and probably won't --
>> nested TCG with QEMU doesn't count).
>>
>> The best counter-indication for this kind of increased sharing is the
>> *numerous* Xen-related regressions that have slipped through in the
>> past, simply because none of the OvmfPkg maintainers use Xen. (And the
>> Xen project seems to be unwilling or unable to delegate an official
>> reviewer or co-maintainer for the Xen-related code in OvmfPkg, despite
>> my repeated requests.) This has happened under ArmVirtPkg too (I recall
> 
> Who did you email/speak to? I hadn't seen any emails sent by
> you to xen-devel mailing list, but perhaps I missed them?

These emails are not easy to find (even in my own mailbox) because my
calls for help / suggestions for co-maintenance have been scattered over
time, loosely tied to OVMF regressions on Xen, or new Xen features in OVMF.

Keyword searches didn't help much, but I managed to find this email, for
example:

http://mid.mail-archive.com/f5e03398-33ca-c90d-743f-691d927657d3@redhat.com

Anthony, Gary, and xen-devel were addressed (among others). On 09/08/16
12:24, I wrote:

> Now, if you create a new platform (DSC + FDF) for Xen, that sort of
> forces someone from the Xen community to assume co-maintainership for
> the Xen bits. (Hopefully those bits would be easily identifiable by
> pathname.) I'd welcome that *very much*.

I remember more (for example I distinctly remember inviting Gary), but I
can't locate that message now.

On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote:
> It should be fairly simple to expand the 0-day OSSTest to build
> TianoCore and launch guests with it as a nice regression test.

The point is to catch regressions before they are merged. This requires
someone who uses Xen every day to review and/or test patches posted to
edk2-devel that affect Xen code in OVMF.

(If the OSSTest tool can identify and pick such patches from edk2-devel
automatically, that would work too, of course.)

Thanks,
Laszlo