-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Source build and VMR should move to CentOS Stream 10 and Alma Linux 10 in main #4890
Comments
I also saw some Alma 8. We should ensure we're using Alma 10 in FYI: Merged version of the doc: https://github.com/dotnet/runtime/blob/main/docs/project/os-onboarding.md |
It seems like we will have four onboarding / build models:
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: |
@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 |
That helps and I'll link to it. Some things to consider:
The goal is that a repo person (not a SB person) knows what to do on their repo. |
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.
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 inrelease/
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:
The text was updated successfully, but these errors were encountered: