Microsoft has announced they will transform their fine-grained repository structure for .NET Core to consolidate a number of foundational .NET Core repositories, including dotnet/coreclr and dotnet/corefx.
As Microsoft engineer Stephen Toub explains, the original decision to keep separate repositories was aimed to increase developer productivity, but led to a number of complications, including confusion about which repo an issue belongs to, more complexity when sharing source code or setting up an installable runtime, cross-repositories PRs, duplication of efforts and lack of consistency.
Part of those problems stems from the deep, complex dependencies entangling the runtime, CoreLib, and other core libraries, but it is not specific to them only. For example, dotnet CLI is also split across several repositories, which makes it harder to build a working installer. In addition, Toub recalls the effort to consolidate ASP.NET 55 repositories down to five, which did not entirely solve all collaboration issues. Hence the need to move to a single, consolidated repo:
We plan to combine dotnet/coreclr, dotnet/corefx, dotnet/corert, dotnet/core-setup, and the relevant portions of mono/mono into a new dotnet/platform repo. Everything needed to build and produce the Microsoft.NETCore.App shared framework will be in this repo.
Besides this, the dotnet/aspnetcore repo will be moved under the dotnet organization to simplify issue and permission management and will host a few additional ASP repositories, such as aspnet/blazor. It is not clear, though, whether aspnet/entityframeworkcore will be consolidated as well. Likewise, dotnet/toolset and dotnet/sdk will be combined into the dotnet/cli repo.
All existing issues and history will be migrated to the new dotnet/platform repo. Given the complexity of the task, Microsoft will not use GitHub issue migration, but will work with GitHub engineers to carry that through on the backend. Toub says Microsoft engineers will also make the effort to clean up the consolidated repository history by removing incorrectly committed binaries and multitudes of automated PRs.
Some rough calculations suggest this could end up significantly reducing the size of the repos as well as the time it takes to clone, which should not only help developers approaching the project but also CI.
Microsoft announcement was met with approval by several .NET contributors, but StackOverflow engineer Nick Craver warned that the cost of contributing to a repo while it is being merged into another may hamper contributions from the community until things settle. One part of Microsoft's plan that raised some concerns was getting rid of the dotnet/corert repository and migrate some portions of it to ad-hoc feature branches. This was considered not optimal because it would hide corert and possibly hamper external projects relying on it, such as those requiring single-file, zero-dependency shared libraries for apps that do not support loading .NET assemblies.
