Announcing the .NET Virtual Monolithic Repository

> This issue is a locked mirror of https://github.com/dotnet/arcade/issues/11584. See that issue for discussion.

# Announcing the .NET Virtual Monolithic Repository

Building the .NET product from individual product repos in the [dotnet](https://github.com/dotnet) organization is a complex process requiring orchestration infrastructure that is available only to Microsoft. This is a hindrance to the .NET community as it's currently not possible to easily reproduce the official product build in the open. Furthermore, the complexity of the official build and release infrastructure tends to grow over the years. This presents many reliability and sustainability challenges.

To address the abovementioned issues, **we'd like to announce a new repository** - https://github.com/dotnet/dotnet - which is the first step on the way to simplify building and shipping of .NET and making the product build process transparent to and reproducible by the community.

This new repository is a **Virtual Monolithic Repository (VMR)**. It includes all the code needed to build the .NET SDK, mirrored from the individual product repos (such as [dotnet/roslyn](https://github.com/dotnet/roslyn) or [dotnet/runtime](https://github.com/dotnet/runtime)). It also includes [source-build](https://github.com/dotnet/source-build), our whole-product build system used to build .NET by our Linux partners.

The VMR has the following main characteristics:
- **Monolithic** - The repository is monolithic so that a single commit fully identifies the whole source code necessary to build the .NET SDK
- **Virtual** - It's a mirror (not a replacement) of the individual product repos that make up the whole product, placed side-by-side in one repository. Changes to the underlying individual product repositories are synchronized to the VMR.
- **Experimental** - Currently, the repository is part of our initiative to streamline the release process, not meant to be depended on. We reserve the right to delete the current instance and create a new, different one in its stead. We expect the repository to be persistent by the release of .NET 8 Preview 1, planned for February, 2023.

The repository is a work-in-progress and has a lot of [limitations](https://github.com/dotnet/dotnet#limitations) but we believe that even with these limitations it can be already useful in a variety of scenarios.

## 🎯 Goals of the Virtual Monolithic Repository

- The main purpose of the [dotnet/dotnet](https://github.com/dotnet/dotnet) repository is to have all source code necessary to build the .NET product available in one repository and identified by a single commit.
- The VMR also aims to become the place from which we release and service future versions of .NET to reduce the complexity of the product construction process. This should allow our partners and and 3rd parties to easily build, test and modify .NET using their custom infrastructure as well as make the process available to the community.
- Lastly, we hope to solve other problems that the current multi-repo setup brings:
- Enable developers to make and test changes spanning multiple repositories.
- Fulfill requirements of .NET distro builders such as RedHat or Canonical to natively include .NET in their distribution repositories.
- Simplify scenarios such as client-run testing of bug fixes and improvements. The build should work in an offline environment too for certain platforms.
- Enable the standard [down-/up-stream open-source model](https://github.com/dotnet/arcade/blob/main/Documentation/UnifiedBuild/VMR-Upstream-Downstream.md).
- More efficient pipeline for security fixes during the CVE pre-disclosure process.

## 📖 Further reading

In case you are interested in knowing more about the why's and how's of VMR's purpose, design and architecture, you may find the following set of documents interesting:
- [VMR's Design and Operation](https://github.com/dotnet/arcade/blob/main/Documentation/UnifiedBuild/VMR-Design-And-Operation.md)
- [Upstream/Downstream Relationships](https://github.com/dotnet/arcade/blob/main/Documentation/UnifiedBuild/VMR-Upstream-Downstream.md)
- [Code and Build Workflow](https://github.com/dotnet/arcade/blob/main/Documentation/UnifiedBuild/VMR-Code-And-Build-Workflow.md)
- [Strategy for Managing External Source Dependencies](https://github.com/dotnet/arcade/blob/main/Documentation/UnifiedBuild/VMR-Strategy-For-External-Source.md)

The build of the VMR is made possible by the [.NET Source-Build](https://github.com/dotnet/source-build).

## 💬 Discussion

You can share your thoughts on the VMR or see what others are saying at https://github.com/dotnet/arcade/issues/11584

This is a locked mirror of dotnet/arcade#11584, so start with that issue and the linked VMR design and operation, upstream/downstream, code and build workflow, and external source dependency documents. The announcement defines no implementation task, files to edit, tests to run, or completion criterion.

Written by the indexing model from the issue text.