Re: [edk2-devel] Adding Bhyve support into upstream EDK2

["Laszlo Ersek" <lersek@redhat.com>]

On 03/07/20 08:39, Laszlo Ersek wrote:
> Hi Jiewen,
> 
> On 03/07/20 02:43, Yao, Jiewen wrote:
>> Just saw Laszlo's email. Similar feedback. Especially, I like the regression test part.
> 
> Thanks.
> 
>> I am not sure how many virtual platforms we will have eventually.
>> If there are more and more, maybe we can create a new edk2-virt-platform repo, and put them together there. (Similar to edk2-platform repo for the physical platform)
> 
> Regarding the last part ("move them together here") -- I'm 100% opposed
> to removing OvmfPkg and ArmVirtPkg from edk2. They *must* remain in the
> exact same git repository where the core (MdePkg, MdeModulePkg,
> CryptoPkg, SecurityPkg, UefiCpuPkg, ...) lives too, and share a common
> git history.
> 
> ArmVirtPkg and OvmfPkg move very closely together with the core, most
> significant ArmVirtPkg and OvmfPkg contributions need changes (and
> therefore introduce new dependencies) on the core. Managing such
> dependencies is a nightmare evein with git submodules; it only works if
> the git history is shared. This problem is not theoretical, it already
> has a bad effect on edk2-platforms.
> 
> [...]

... now I expect this might raise the question why my stance on
consuming submodules in edk2 itself is different -- i.e., why it is that
I *like* edk2 to consume OpenSSL, brotli (TianoCore#2558,
TianoCore#2559), Oniguruma (TianoCore#2073) etc through git submodules.

Here's why: because we mostly treat those projects as black boxes.

- The contributor audiences for those projects hardly overlap with edk2
developers.

- The development workflows sharply differ.

- The rate of change introduced into those projects, for addressing
consumer (i.e., edk2) needs, is very low.

This is very much not the case between edk2, and: ArmVirtPkg and OvmfPkg
(and, again edk2-platforms).

Thanks
Laszlo