APIs out of scope in CoreFX - 'CoreFXExtensions' repo?

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

https://docs.microsoft.com/dotnet/core/

MIT License

15.48k stars 4.76k forks source link

APIs out of scope in CoreFX - 'CoreFXExtensions' repo? #22228

Open karelz opened 7 years ago

karelz commented 7 years ago

Over time we have identified bunch of useful APIs, which we think don't belong into CoreFX repo, because they are more advanced, or just don't fit. Here's the list to keep track of them with common explanation & list which can be reused later if/when we (or community) creates something like CoreFXExtensions

PowerCollections from CodePlex - Originally created by Wintellect for .NET team. The license should be compatible to grab it. It is generally useful API set
Graphs APIs - dotnet/runtime#20730. Options/alternatives: MSAGL - see https://github.com/dotnet/corefx/issues/17403#issuecomment-307589692, or CodePlex QuickGraph
ParallelExtensionExtras (@stephentoub mentioned it in dotnet/runtime#14088)
Sorting algorithms for nearly-sorted inputs (see dotnet/runtime#14800)

PLEASE: If you want to argue that something is in scope of CoreFX, vs. not, please take the discussion into specific issue. I will delete such replies from this thread.

mikedn commented 7 years ago

For graphs someone should probably take QuickGraph from CodePlex and make it work well on .NET Core (I assume it doesn't, it wasn't updated for quite some time). Though it's questionable if this has anything to do with corefx or corefxextensions.

tarekgh commented 7 years ago

@karelz I am not sure if such issues is actionable. I would suggest to have a doc in corefx having such information and if anyone want to bring any library to corefx or corefxextensions should open a separate issue for such request. the document can have the information about the requirements for what can goes to corefx and what can go to corefxextensions. having issue like this will be very hard to track what need to be done and will include a lot of discussion for different types which will be confusing and not effective.

karelz commented 7 years ago

@tarekgh this is master issue to dupe others against. I will manage the discussion here. It is IMO better to have a place for discussion than one-way doc info where no one can ask. This is the forming start of the overall "what belongs where" doc. If you are worried about this approach, let's chat.

tarekgh commented 7 years ago

My worries is regarding the discussions will be related to different libraries. For example, we should have a separate issue for PowerCollections to decide about this library. if we use this issue to discuss all proposed libraries that will be very messy and not focused.

tannergooding commented 7 years ago

I agree. I think it would be useful to have an explicit tag to label discussions with (Possible-CoreFXExtension).

This would allow users to clearly see that the issue is not going to get merged into CoreFX, but it seems like a reasonable thing that could exist in the other library CoreFXExtensions.

The issue can then be closed and moved to the CoreFXExtensions repo. Users can continue discussion, including whether or not they feel it is something that should be in CoreFX proper in the new thread.

karelz commented 7 years ago

My worries is regarding the discussions will be related to different libraries.

@tarekgh see my original top-post:

PLEASE: If you want to argue that something is in scope of CoreFX, vs. not, please take the discussion into specific issue. I will delete such replies from this thread.

In general I am against creating new labels. It just creates mess based on my experience, unless there is strong driving force behind it. I would prefer to keep the discussion on specific issues (linked from here), maybe even closed. And keep the list of all such areas here. We can announce info about if/when CoreFXExtensions (or something similar) is coming on this issue.

tarekgh commented 7 years ago

why we need to track these differently than any other requests like introducing a new APIs or porting some existing APIs?

karelz commented 7 years ago

Because they don't belong into CoreFX - that's information we're communicating by closing the issues. And there's no better place to track the list / announcement about the next steps in the space.

ghost commented 6 years ago

QuickGraph was ported to https://github.com/pelikhan/quickgraph by original author @pelikhan.

pelikhan commented 6 years ago

I am in 17/2D if you want to chat

stephentoub commented 5 years ago

@karelz, what work to be done in corefx is this issue tracking?

karelz commented 5 years ago

@stephentoub this is catch-all for things that do not belong into CoreFX, but we did not provide clear guidance where they belong yet ... it is in extension something our team owns (to make final decision and provide guidance). At minimum it tracks adding clear description in docs in CoreFX repo.