Evaluate and determine feasibility of Linux Distro partner VMR branches and Microsoft VMR branches being identical

[mmitche]

One of the foundational rules of Unified Build is that our distro partners should be building the same commits as Microsoft builds. See https://github.com/dotnet/arcade/blob/main/Documentation/UnifiedBuild/Foundational-Concepts.md#public-open-source-net-releases-must-be-buildable-by-net-distro-maintainers-from-a-single-commit-in-the-upstream-repository. This does not mean that Microsoft builds the exact same product as distro partners. Build behavior may be different (restoring different packages, inclusion of non-OSS components in the Windows Build, etc.). It simply means that the ideal is that the commits we build will be the same as what our distro partners can build. There should be no permanent delta between the public upstream branches and what Microsoft builds.

It is time to test this in practice. Our distro partners have more restrictive rules about what may appear in the VMR with respect to binaries and source code licenses. As a result, we currently cloak files that do not abide by their rules but are not required to build the source-built Linux .NET products. Some of these cloaked files will be required to release the Microsoft-built product. My general sense is that most cloaking is generally a "bad" code smell w.r.t. to licensing and checked in binaries, and most should be able to be removed.

We need to evaluate all the currently cloaked items and determine the following:

• Is the cloaked item required for Microsoft's build?
• If it is not, then the cloaking entry can stay, but should the file be in the source repo at all? What purpose does it serve?
• If the item is required for Microsoft's build, then what will it take to get rid of the cloaking? Example resolutions might include:
  • Re-evaluation of a license file (is the license problematic? Is it an installation artifact, or talking about actual source code)
  • Moving non-OSS compatible licensed code to another repo (should the code have been in the repo in the first place?)
  • Removal of binaries via restoring them from a package. Test assets commonly in this category.

T-shirt size: L. There is quite a bit of unknown here. This may be largely mechanical, an easy change. or it may uncover some serious issues.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[mthalman]

/cc @dotnet/distro-maintainers

[mmitche]

T-shirt size: L or XL