Re: [Xen-devel] [edk2] [PATCH] Maintainers.txt: update OvmfPkg maintainership
On Wed, Aug 23, 2017 at 11:04:06AM +0200, Laszlo Ersek wrote: > 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.) > We have been testing OVMF in osstest since two or three years ago, albeit the test cases are limited to booting and installing a guest. The regression is going to be caught after patches are merged though because we're pulling from the official OVMF tree. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] [PATCH] Maintainers.txt: update OvmfPkg maintainership
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 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [edk2] [PATCH] Maintainers.txt: update OvmfPkg maintainership
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-de...@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
