State policy on mscorlib

[Alexx999]

I see a lot of confusion around mscorlib, since it's part of coreclr project, but it feels more like part of corefx. Some issues are open here (and sent to coreclr, like #14039), some are open there and sent to here (like #14081).
Plus, there is some classes that exist in both repos with some differences like ConcurrentDictionary (for example of pull request open to one repo and sent to another see dotnet/coreclr#63).

And even tests for runtime classes are in corefx (but runtime classes itself are in coreclr).

There should be something like "rule of a thumb" to rule this out.

[mikedn]

It may also worth discussing how .NET Native fits into all this, it has been mentioned in the .NET Core open source blog post but details about it are ultimately scarce. And the problem is, some of the issues that show up here touch code that doesn't exist or is different in .NET Native.

For example, dotnet/coreclr#81. The corresponding .NET Native doesn't appear to have this issue to begin with, it doesn't use Convert.ChangeType.

Or dotnet/corefx#603, where the cost of an extra allocation for a distinct lock object was briefly mentioned. Guess what, if you use object as lock on .NET Native you get an extra allocation anyway because it can't lock on arbitrary objects, it can only lock on the a special Lock class.

[weshaggard]

@AlexGhiondea added some of this information in the CoreCLR contribution guidelines, as he calls out the rule of thumb should be: Start with the CoreFX repository for any managed API changes and the CoreCLR repository for any runtime changes unless otherwise directed by the area owner. We are still working on figuring out how to work in the open and so please do keep asking the questions and we will attempt to address them and provide the necessary guidance.

@mikedn as for how .NET Native fits in we aren't quite ready to talk about that because we haven't figured out our plans for it yet. Stay tuned!. I will say that the reason the tests for things like System.Runtime, etc are in the CoreFx repo is because logically they are an abstraction for the core APIs over the runtime/core assembly which are intended to be ran on the different .NET runtimes (i.e. Full .NET Framework, .NET Core, .NET Native, etc) to ensure the behavior is the same. So they don't exactly belong next to just one of the implementations (i.e. mscorlib in the CoreCLR repo) as our goal will eventually be to use those tests for the different runtimes.

[weshaggard]

I'm closing this issue now please to feel free to reopen if there is further clarification needed.