Source build and VMR should move to CentOS Stream 10 and Alma Linux 10 in main

[richlander]

A group of us have been working on new guidance for OS onboarding. Some new (well, not new, but newly written down) guidance came out of that effort.

Being active in main enables being lazy in release/.

The idea here is that if we move main to the bleeding edge, we get the double benefit of bleed-edge coverage and can (in many cases) avoid EOL remediation cost in release/ branches. Updating EOL OS references (if we don't have to) is a waste of time and compute resources.

Source build is an important cross-cutting OS reference that shows up in a lot of repos. Of all the projects we have, source build should be the most aligned with this philosophy to have the least impact footprint on other repos.

If we feel like this will result in a loss of coverage, we should get the coverage a different way.

Related:

• Add doc on OS onboarding runtime#112026
• Update Ubuntu and CentOS Stream versions runtime#112124
• Adopt Azure Linux for build images sdk#46721

[richlander]

I also saw some Alma 8. We should ensure we're using Alma 10 in main as well.

https://github.com/dotnet/sdk/blob/d500e00f5adffea79148f8cf83083e1d92bdccd5/eng/pipelines/templates/variables/vmr-build.yml#L69-L72

FYI: Merged version of the doc: https://github.com/dotnet/runtime/blob/main/docs/project/os-onboarding.md

[richlander]

It seems like we will have four onboarding / build models:

• Repo native code
• Repo managed code
• Source build
• VMR

Perhaps those last two are the same?

We now have a doc for runtime and have one coming for aspnetcore. That covers the first two models. We should write another doc for the other two. Such a doc should explain why we need to move to CentOS Stream 10 and Alma Linux 10 now.

Can your team own writing these one or two docs @MichaelSimons? We expect the aspnetcore one to be much shorter than the one I wrote. These can be the same. I'm going to write a short meta doc that links to all these docs and that will be intended to cover all the teams/repos.

Related:

• Create an OS onboarding doc aspnetcore#60281

[richlander]

@jkoritzinsky

[MichaelSimons]

Can your team own writing these one or two docs @MichaelSimons? We expect the aspnetcore one to be much shorter than the one I wrote. These can be the same. I'm going to write a short meta doc that links to all these docs and that will be intended to cover all the teams/repos.

@richlander - I think the Guidelines for Platforms Tested in CI covers some of what you are asking for. It doesn't contain any instructions for what changes are actually needed.

Regarding updating to Alma Linux 10, the reason for the Alma Linux leg is specifically to validate compatibility with building with the min glibc version. This has been a source of breakage for distro maintainers. This is called out in Guidelines for Platforms Tested in CI

[richlander]

That helps and I'll link to it.

Some things to consider:

• The distinction between main and release is hinted at but not explicit.
• Does a given repo need coverage from all those distros? And same for x64 vs Arm64?
• Is VMR vs source-build the same thing?
• Who needs to test with oldest Alma? Do we really need to test with the oldest Alma for SB?

The goal is that a repo person (not a SB person) knows what to do on their repo.