Sean,

This is the reason that OvmfPkg was kept in the edk2 repo so only a single repo is required for local dev testing and CI testing. Same reason for the EmulatorPkg.

The current rule for the edk2 repo is common firmware packages and virtual/emulated platforms.

The fact that there has not been bandwidth to implement the CI testing for OvmfPkg or EmulatorPkg is not a reasonable reason to remove them.

Mike

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean via Groups.Io
Sent: Tuesday, March 10, 2020 12:11 PM
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; devel@edk2.groups.io
Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2

On Tue, Mar 10, 2020 at 10:54 AM, Ard Biesheuvel wrote:

This means we can reasonably require any contributor not to regress on
those platforms, given how they have full access to it, and this is
actually where i would like us to take the next step when it comes to
ci automation, i.e., automatically flag PRs that break the boot on a
selected set of qemu based configs.

I appreciate the viewpoint but I don't think edk2 has "required" this yet and I would push back on that if it was brought up for community discussion.  As you know I believe contributing to edk2 is much too hard already, and filled with custom edk2 workflows, and this one would only make it more of a burden to contribute.  

I do however agree that if this is important to the edk2 community, systems/automation should be setup to run this type of thing.  If that happens, i don't think it is much harder to do it for multi-repo than single repo and if done right for multi-repo then other platforms can opt in as well and the efforts to build this infrastructure will scale well beyond a single virtual platform.

Thanks
Sean