cc @akoeplinger

Triage: @richlander do we have any documentation on how customers should go about adding these community rids and which ones we'll take?

There is nothing new here, loongarch is supported since net60 (see the rest of this file). Its ILCompiler support was added recently in net90.

@am11 we (SDK team) don't have good knowledge of what platform capabilities are incoming or in flight - is there an epic for 'light up loongarch for XYZ functionality' or something that helps us know that this is part of some unified unit of effort? Or is there another team that should be reviewing this?

These are not so much community RIDs as community architectures.

The big push on RIDs in the past was to get us focused on linux, which we did. We have no issue with adding new architectures. They are not coming at near the pace of distros.

I have no concerns with these changes.

@jkotas @agocke @elinor-fung

Thanks for the clarity folks - in the future an epic or something would make these kinds of PRs much more routine.

I agree with @richlander .

The architecture that requires hardcoding the lists of RIDs in the SDK is a bit of unfortunate. I think it would be better to just depend on a package availability, but that's not a simple fix.

in the future an epic or something would make these kinds of PRs much more routine.

This is our documentation for contributing ports: https://github.com/dotnet/runtime/blob/main/CONTRIBUTING.md#contributing-ports