Runtime: dotnet/runtimelab repo proposal
Encouraging .NET Runtime Experiments
Experimentation with new ideas is essential for successful innovation. However, we do not have a consistent or successful pattern for running larger scale experimental projects based on the .NET runtime today. For lack of better options, .NET runtime experiments live in dotnet/runtime directly (Utf8String) or in separate repo with unclear messaging (CoreRT). This discourages innovation and creates confusion among both our team and customers. That's the opposite of what we want.
We need to establish a pattern to run experimental projects that:
- Maintains a clean separation between experimental and shipping projects, for all source code, issue tracking, engineering system and public perception.
- Allows experimental projects to focus on their unique value, while leveraging as much code as possible from dotnet/runtime, and engaging whomever they want to participate/collaborate.
- Encourages fixes and improvements (that may be required to enable the experiment, but are valuable in general) to go directly to dotnet/runtime:master.
We are proposing to create a new dotnet/runtimelab repo as a shared place to hosts experimental projects based on the .NET runtime. This repo is going to be a fork of dotnet/runtime. Each experiment is going to live in its own branch in this repo. The master branch of dotnet/runtimelab is going to have the list of experiments and the branches they use to help with discoverability.
Questions and Answers
How is this different from dotnet/corefxlab?
The spirit is the same as with corefxlab. The key differences are that this spans the whole .NET runtime and that the experiments can be done across full stack by leveraging code from dotnet/runtime. The active experiments from corefxlab will be moved to runtimelab, and corefxlab repo will be archived.
Where are the experimental packages from runtimelab going to be published?
The packages are going to be published to dedicated NuGet feed. The packages are not going to be published to nuget.org. Same as corefxlab today. We only publish packages to nuget.org that we can commit to customers using in production apps.
What is the support policy for experimental projects?
The packages from dotnet/runtimelab are not supported by the .NET team for use in production. The packages published by dotnet/runtimelab do not have stable releases nor receive servicing fixes. Same as corefxlab today.
Do all experiments need to be done runtimelab?
It is still fine to do small scale experiments in dotnet/runtime directly if:
- The experiment contains modest amount of code (no more than several thousand lines)
- The experiment is off by default and activated via configuration switch
- The experiment does not introduce any new public APIs or NuGet packages
An example of a small scale experiment that is perfectly fine to do in dotnet/runtime directly is ValueTask Pooling.
What does qualify the experiment to be included in dotnet/runtimelab?
The experiment must be sponsored by a dotnet/runtime contributor with commit permissions who has enough time to run it. The contributor and commit right permission model for the dotnet/runtimelab is identical to dotnet/runtime.
How does an experiment grow into a shipping .NET runtime feature?
The process for this is no different from ordinary features. The experiment has to demonstrate its value, public APIs need to go through API review, etc. Logistically, the relevant code is manually copied from dotnet/runtimelab to dotnet/runtime and deleted in dotnet/runtimelab. Same as corefxlab today.
What happens with dotnet/corert?
The Native AOT form-factor CoreRT project, based on the CoreCLR GC and RyuJIT, is going to be one of experiments hosted in dotnet/runtimelab. This is different from the plan published in Consolidating .NET GitHub Repos announcement.
What is going to be the engineering system for dotnet/runtimelab?
The engineering system for dotnet/runtimelab is going to be focused on ensuring that the experimental projects are usable and not completely broken. It is not going to guarantee high quality across all platforms. As such, it is going be much more lightweight compared to the engineering system of dotnet/runtime.
If an experiment requires additional validation, it will be addressed on a case-by-case basis.
jkotas
All 5 comments
I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.
Dotnet-GitSync-Bot
on 29 Apr 2020
Logistically, the relevant code is manually copied from dotnet/runtimelab to dotnet/runtime and deleted in dotnet/runtimelab. Same as corefxlab today
I suppose this means rebase the fork and then merge from the fork, right?
Sebazzz
on 29 Apr 2020
Thanks for getting this proposal up! Do you have an idea of how this might work with larger-scale changes?
For example, let's say we were trying to stand up Span<T> today. This would touch almost every facet of the product: corelib, System.Runtime APIs, and pretty much every System.* package, really. Is the idea that the "span-ified" runtime would basically be an entirely separate SxS release? So anybody who wanted to use it would need to pull down the experimental corelib, and the experimental System.Runtime, (and the rest of the SDK), etc.?
GrabYourPitchforks
on 29 Apr 2020
Do you have an idea of how this might work with larger-scale changes?
I expect that the experiments will be building runtime refs and packs that will allow people to publish self-contained app with the experimental runtime using regular SDK. I do not expect that the experiments will try to build shared framework integrated into SDK.
pretty much every System.* package
The goal of the experiments should be to gather the data to prove the feature. It do not expect that we will do 100% of the productized implementation in dotnet/runtimelab, and then just integrate it over. It will be more like do first 10%-20% in runtimelab, and if it is proven, do the remaining 80% in dotnet/runtime.
I suppose this means rebase the fork and then merge from the fork, right?
Depends. It is one of the possible strategies. For the experiments we have done in the past, we often found that we want to do things slightly differently for real or that we do not want to include everything that was prototyped in the experiment. Selective copy may be more appropriate for these case.
jkotas
on 29 Apr 2020
https://github.com/dotnet/runtimelab is created now and the experiments are starting to live there. Woo-hoo!
https://github.com/dotnet/runtimelab/blob/master/README.md has a link back to this issue for context.
jkotas
on 25 Jul 2020
Related issues
omajid
路
3Comments
nalywa
路
3Comments
chunseoklee
路
3Comments
EgorBo
路
3Comments
bencz
路
3Comments
Most helpful comment
I expect that the experiments will be building runtime refs and packs that will allow people to publish self-contained app with the experimental runtime using regular SDK. I do not expect that the experiments will try to build shared framework integrated into SDK.
The goal of the experiments should be to gather the data to prove the feature. It do not expect that we will do 100% of the productized implementation in dotnet/runtimelab, and then just integrate it over. It will be more like do first 10%-20% in runtimelab, and if it is proven, do the remaining 80% in dotnet/runtime.
Depends. It is one of the possible strategies. For the experiments we have done in the past, we often found that we want to do things slightly differently for real or that we do not want to include everything that was prototyped in the experiment. Selective copy may be more appropriate for these case.