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

[Laszlo Ersek <lersek@redhat.com>]

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
ACPI vs. DT related changes -- surprisingly, even *that* selection is
specific to the virtualization platform.)

The bottleneck in open source development is not writing code, it is
reviewing and regression-testing code. (This is painfully obvious in
Linux kernel and QEMU development, but the same can be experienced on
edk2-devel as well.) Therefore OvmfPkg's structure should match the
distribution of OvmfPkg's active stake-holders over architectures and
virtualization platforms.

IMO the current code sharing between OvmfPkg and ArmVirtPkg, while
certainly not 100% polished, is workable -- meaning that it mostly
corresponds to the stakes that ArmVirtPkg and OvmfPkg maintainers and
long-term contributors hold in the shared modules.

In fact, these stakes would be much better reflected if Ard *too* were a
Maintainer for OvmfPkg.

Thanks
Laszlo