Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mono + dotnet/runtime Migration #1018

Closed
21 of 24 tasks
steveisok opened this issue Dec 18, 2019 · 15 comments · Fixed by Woodpile37/runtime#5 or Woodpile37/runtime#18
Closed
21 of 24 tasks

Mono + dotnet/runtime Migration #1018

steveisok opened this issue Dec 18, 2019 · 15 comments · Fixed by Woodpile37/runtime#5 or Woodpile37/runtime#18
Assignees
Labels
area-Infrastructure-mono tracking This issue is tracking the completion of other related issues.
Milestone

Comments

@steveisok
Copy link
Member

steveisok commented Dec 18, 2019

These are the high level sets of tasks / priorities leading up to and after parts of mono are migrated into dotnet/runtime.

Before Migration

  • Determine steps needed to enable dotnet/runtime testing for mono
  • Enable PR Sync Bot and test

Migration

Post Migration

Priority I (Near completion)

Priority II

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-Infrastructure-libraries untriaged New issue has not been triaged by the area owner labels Dec 18, 2019
@jkotas
Copy link
Member

jkotas commented Dec 19, 2019

What is PR Sync Bot?

@danmoseley
Copy link
Member

Are these worth calling out specifically

  • Add build configurations for iOS and Android
  • Porting of code into System.Native
  • Porting of code into libraries, changing #ifdef to partial classes in many cases
  • Add build configuration for Windows desktop (?) and CI (?)

Post migration

  • Size measurements, trimming as necessary, infrastructure to protect size.

@danmoseley danmoseley added this to To do in Infrastructure - Consolidation via automation Dec 19, 2019
@marek-safar
Copy link
Contributor

@danmosemsft The goal is to get the build going first. Any implementation changes will come once the infrastructure is in place and working.

@lambdageek
Copy link
Member

A few more post migration tasks:

@jkotas jkotas mentioned this issue Dec 20, 2019
@akoeplinger
Copy link
Member

I just opened the PR that adds Mono to the repo: #1912 :)

@borgdylan
Copy link
Contributor

What will the story be for those running mono on Linux? Would there still be a way to build it and install it via makefiles? Will there be a similar story for .NET 5 as a replacement?

@akoeplinger
Copy link
Member

@borgdylan Mono as you know it will stay around as an option, but for .NET 5 the packaging/distribution is a bit different.

@shahid-pk
Copy link
Contributor

shahid-pk commented Jan 23, 2020

is this just port of monovm and aot , which will use .net core's gc . Or is the entire mono runtime along with mono's gc is getting ported here ?
Interested because mono vm and JIT runs in many places where .net core does not and .net core's gc is way better than mono's gc. (my opinion)

@akoeplinger
Copy link
Member

It is the entire Mono runtime including Mono's GC (sgen).

@tibel
Copy link

tibel commented Jan 24, 2020

Is there a plan to port Mono to use the .NET Core GC?
I would prefer having one garbage collector for only in terms of testing and maintenance.

@jkotas
Copy link
Member

jkotas commented Jan 24, 2020

Is there a plan to port Mono to use the .NET Core GC?

Xamarin and Blazor are the primary workloads for Mono. CoreCLR GC (as is) is likely a worse option for these workloads than the current Mono GC. We may experiment with it, but the Mono GC is here to stay until we have a data that confirm the .NET Core GC would be a better choice for the primary Mono workloads.

@richlander
Copy link
Member

I don't see anything in that list for publishing runtime packs. Is that missing? If so, it seems like it should be added. W/o that, there isn't a user experience.

@jaredpar
Copy link
Member

jaredpar commented Feb 6, 2020

When doing the planning for migrating the mono runtime into the repository there was no cleanly defined user experience. Given that we decided to cut the runtime packs and publishing because there wasn't a clear goal for us to plan around. Instead we decided to separate migrating mono into the runtime and then work on publishing, official builds and packaging once we had a defined scenario to plan that around.

Is that available now for us to look at?

@marek-safar marek-safar removed the untriaged New issue has not been triaged by the area owner label Feb 13, 2020
@directhex directhex moved this from To do to In progress in Infrastructure Backlog Mono Mar 6, 2020
@marek-safar marek-safar added the tracking This issue is tracking the completion of other related issues. label Jul 8, 2020
@ViktorHofer ViktorHofer added this to the 5.0.0 milestone Jul 15, 2020
@ghost
Copy link

ghost commented Aug 4, 2020

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

@steveisok
Copy link
Member Author

For the most part, I think we're migrated. I think what's left is for 6.0 and beyond.

@steveisok steveisok modified the milestones: 5.0.0, 6.0.0 Aug 4, 2020
Infrastructure Backlog automation moved this from 6.0.0 to Done Jul 12, 2021
@dotnet dotnet locked as resolved and limited conversation to collaborators Aug 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Infrastructure-mono tracking This issue is tracking the completion of other related issues.
Projects
No open projects