Laszlo,

Except for a very few platforms that are in the current edk2 repo today, everyone building products has to deal with this "split repo" reality.  It gets even harder when you account for different business units, different silicon partners, IBVs, ODMs, open source, closed source, secret projects, and so on.  The reason I want to bring forth the Project Mu tools to Edk2 is that everyone is forced to reinvent this process and tooling every time and it doesn't work very well.  If edk2 continues to ignore the challenge of most downstream consumers it continues to lead to the results of today.  Very high cost of integration.  Very low quality of integrations and very few integrations into products (meaning products don’t get updates).  The last couple of years has brought significant light to the challenges of updating platform firmware and has shown that the majority of products don't/can't get updates resulting in customers not being fully protected.  

Regarding submodules and boundaries. 
I completely agree except that I believe there are numerous boundaries within a UEFI code base.  As mentioned above one of our goals with splitting the code repositories is to have all code within a repository owned/supported by a single entity.  Another point to splitting is attempting to get code with business logic separated from core/common code.  Business logic often is different across products and if intermixed with core logic it adds significantly to the cost of maintaining the product.  Along your same thinking these different repositories do have different development models.  Many are closed source and have proprietary change request process.  They all release on different cadences, different dependencies and very different testing expectations so without a framework that provides some support this leads to challenging and complicated integration processes. 

 

Single repo:

It is not possible for most products.  Again when integrating large amounts of code from numerous places all with different restrictions it is not practical to have a single bisectable repository with good history tracking.  Some entities still deliver by zip files with absolutely no src control history.  Many entities mix open and closed source code and make hundreds/thousands of in-line changes.  I just don’t see a path where a product can have 1 git-merged repo and still be able to efficiently integrate from their upstream sources and track history.   

 

 

These tools are just a first step down a path to reshaping tianocore edk2 to be easier to consume (and update) by the ecosystem that depends on Edk2 for products.  These tools also have solutions for Ci builds, binary dependencies, plugins, testing, and other features that edk2 will need for some of the practical next steps. 

 

Brian,

I would really like to hear about the challenges your team faced and issues that caused those solutions to be unworkable.  Project Mu has and continues to invest a lot in testing capabilities, build automation, and finding ways to improve quality that scale.

 

Thanks

Sean