Hi all,

First, I'd like to clarify that I completely support the development of open source edk2 platforms and this observation is only intended to suggest an improvement for interoperability with edk2 development and not to detract from the great work happening in open source platforms.

There's currently an expectation that edk2-platforms must build with edk2/master. I'd like to address the present lack of infrastructure and uniformity in edk2-platforms that, in my opinion, makes this perpetually painful.

1. Inconsistent maintainer support
* Some packages currently do not build. Some packages are not getting updated often.

* Example: Last week I had to update Vlv2TbltDevicePkg which did not build.
* Example: Many packages only document support for old toolchains.

2. Inconsistent toolchain support

To build these according to instruction, a developer needs to install Visual Studio dating back to 2015 (though it is 2020), and multiple versions of iASL, NASM, a separate host OS for Linux/Windows builds, etc.

Just a few quick examples:

* Vlv2TbltDevicePkg documented supported toolchains:

https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/Vlv2TbltDevicePkg/Readme.md

* Compilers: VS13, VS15
* Windows DDK: 3790.1830 in C:\WINDDK\3790.1830
* Python: 3
* iASL: iasl-win-20160527 in C:\ASL
* NASM: 2.12.02 in C:\NASM
* OpenSSL: Latest version in C:\Openssl (add OPENSSL_PATH)

* Platform/ARM supported toolchains:

https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/Readme.md

* OS: A 32-bit or 64-bit Linux host machine.
* Compilers: Visual Studio is not officially supported, experimental support can be found here: [https://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=aarch64-vs]

* Platform/Intel (MinPlatformPkg):
* Compilers: VS15
* Python: 3.7.3
* iASL compiler: latest in C:\ASL
* NASM: latest in C:\NASM

3. Inconsistent build requirements

Many builds use the "build" command. Others have script wrappers with unique parameters. Platforms are free to choose what they do and do not support and developers have to figure it out.

4. Lack of build health indicators

Basically, there is no public CI across platforms. It is not clear exactly what platform builds are broken, what configurations they are broken against, how long they have been broken, etc.

6. Lack of community testing capability

An edk2 contributor cannot be expected to understand the nuances of every platform in edk2-platforms to always make the right integration decision for a change in edk2. Platform objectives like performance and security vary and are not clearly documented. In turn, this slows progress in edk2. In many cases, edk2 contributors do not have a way to check for runtime regressions in edk2-platforms as they do not possess the platform they're requested to update.


Within the purview of an individual edk2-platforms maintainer, these problems are relatively insignificant, largely due to the somewhat isolated nature of platform development. However, it does not scale well to edk2 contributors that need to build and test N platforms.

While community alignment on build tools, toolchain support, keeping current, and other areas would help, I believe many of the concerns can be mitigated with publicly accessible CI that proves current build support, build health, build commands, allows developer build testing, and potentially even device boot regression testing for those without platforms on hand.

Without such support, I believe platforms can only have a dependency on edk2 (not vice versa). Maintainers move their edk2 pointer when they have verified that their platform properly integrates the latest changes. This is relatively common in relationships with package-based dependencies and how this is typically handled outside edk2-platforms. I believe this is reasonable even with public CI in place unless maintainers understand and accept the challenges and additional support that is involved with being on edk2/master.

I just wanted to give my observation of some recent challenges and see if the community can align on some practices to help simplify edk2-platforms integration and testing.

Thanks,
Michael