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

["Sean" <sean.brogan@microsoft.com>]

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

I don't see the difference besides the mechanics of the operation (which you have described clearly).  To guarantee a repo or repos is "git-bisectable" you need to build and test every commit on your platform.  For example in the recent ArmMmuLib patchset, you were able to build every commit in the patch to identify which one caused the break.  There isn't an enforced process in place to ensure that happens within Edk2.  Thankfully the review process and the developers knowledge allowed the commits to be made in such a way that this was possible.  That doesn't have to change when you move to a submodule.  Also you could put automation in place to enforce and/or test for this scenario.  You can put automation in place to "integrate" into your super project at every commit if you really wanted to and had the resources to run tests on every one of those commits.  Is this type of CI done today for OVMF?

Again this is what nearly all platforms have to do today and we have a lot of experience with bisecting within the submodule to find the error.  The longer you wait between integrations the more costly the bisect is if you have to do it, but this is a choice of the super project owner / platform owner.  Today I assume you make those choices too, they just happen to be within the same repo.  I also assume that if you found the MmuLib bug in a few days you probably wouldn't bisect all the changes but you would review the history to intelligently guess at the most likely candidates and bisect within those commits.

In the end I just don't see the big difference to the platform (OVMF in this case) but I do see the reduced size/noise/content helping all platforms.  Success still relies on good development practices, regular builds, and testing.

Thanks
Sean

[-- Attachment #2: Type: text/html, Size: 1930 bytes --]