4 ms·
If you take a look as these issues, it's clear that they're happy to make the source code very different, i.e. hard/impossible for changes to be automatically p
by matthewwarren 9y ago
If you take a look as these issues, it's clear that they're happy to make the source code very different, i.e. hard/impossible for changes to be automatically ported across.
Just look at how much .NET Framework (Desktop) code they removed from CoreCLR earlier this year!
- https://github.com/dotnet/coreclr/issues/8857 https://github.com/dotnet/coreclr/issues/8857
- https://github.com/dotnet/coreclr/issues/8763 https://github.com/dotnet/coreclr/issues/8763
- https://github.com/dotnet/coreclr/issues/4651 https://github.com/dotnet/coreclr/issues/4651
- https://github.com/dotnet/coreclr/pull/9058 https://github.com/dotnet/coreclr/pull/9058
- avtar 9y ago> Just look at how much .NET Framework (Desktop) code they removed from CoreCLR earlier this year! Perhaps I'm missing something but wouldn't removing Windows specific code from a now cross platform runtime be the obvious thing to do?
- ellism 9y agoFWIW (I work on the .NET Team and I wrote the mirror we use to keep TFS and GitHub in sync). When we started the project we maintained a mirror which kept our GitHub repository and internal TFS branch in sync. After a while, we decided that trying to maintain this was more harm that it was worth (the internal TFS branch used a completely different build system and there were other interactions between code which had been open source and code that hadn't that meant our internal branch was on the floor every few days), in addition it meant that we were carrying around a bunch of effectively dead code in the source tree. We still do mirror some code (mainly the JIT) into TFS to make it easier to share code with the Desktop in an automated fashion. However, for the rest of the code (e.g. the VM and BCL), if there are improvements we want to bring back, an engineer will just port them manually.