On 05/14/20 19:48, Sean Brogan wrote: > Adding another platform to a core repository that might or might not > work at any given time is a burden to all core contributors and doesn't > bring value to the core project.
Platforms that depend on edk2, but are not inside edk2, are near guaranteed to break when core edk2 changes occur. Such external dependencies are impossible to locate with "git grep"; you can't run a git-grep on "all projects in the universe that consume edk2". Even if you manage to identify some high-profile out-of-tree platforms (by sheer diligence, or by those platforms' own CI systems -- doesn't matter), you are effectively prevented from adjusting them in the *right patch order*, as you cannot cover multiple repositories in a single patch series. This is already causing *massive* and everyday pain with edk2-platforms; contributions that would normally take the form of a run-of-the-mill patch series, now have to be split in at least three waves (prepare the core, update external platforms, switch over the core). With in-tree platforms, the approach is of course the same, the difference is that these stages can be managed, and merged, in a unified series of commits. Addressing external dependencies by splitting work into sub-series slows development to a crawl. (BaseTools is no exception. I've agreed to splitting it out because the demand for that seems to be huge, and with careful maintenance of "pip-requirements.txt", and with the features offered by pip virtual environments, it appears technically possible. Conceptually, with these bits in place, the BaseTools <-> edk2 dependency tracking should not lose any safety. It *will* lose efficiency.) Furthermore , I disagree with your "burden to all core contributors" and "doesn't bring value to the project" statements 100%. - I *am* a core contributor (feel free to look up the patches I've contributed, with git-log), - DynamicTablesPkg, EmulatorPkg, FmpDevicePkg, IntelFsp2Pkg, IntelFsp2WrapperPkg, SignedCapsulePkg, SourceLevelDebugPkg, StandaloneMmPkg, UefiPayloadPkg, UnitTestFrameworkPkg carry exactly zero interest for me, - but they are also exactly zero burden to me. So your statement "burden to all core contributors" is false (EmulatorPkg in particular is a platform which sometimes does break), and it does not bother me at all. Then, having bhyve in-tree *does* bring value to the project, because it simplifies the testing and development of core edk2 modules on a new, thus far not officially targeted, hypervisor platform. It exposes edk2 to a wider audience; people using FreeBSD as their everyday desktop will have an easier time running and hopefully developing edk2. Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#59670): https://edk2.groups.io/g/devel/message/59670 Mute This Topic: https://groups.io/mt/74075377/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
