Re: [Xen-devel] [edk2] [PATCH] Maintainers.txt: update OvmfPkg maintainership

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

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?

It should be fairly simple to expand the 0-day OSSTest to build
TianoCore and launch guests with it as a nice regression test.

> 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
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@xxxxxxxxxxxx
> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel