Corefxlab: rename System.Collections.Generic.MultiValueDictionary package

[KrzysztofCwalina]

I think it would be good to have a package with many "advanced" datastructures. Maybe we should just rename System.Collections.Generic.MultiValueDictionary to System.Collections.Power or something like that?

cc: @livarcocc, @jamesqo, @karelz

[karelz]

I would wait with the renaming until we have clear plan for shipping PowerCollections (which repo, when) and decision if we want to make it "AdvancedDataStructures" vs. "just collections" package.
Until then, is there a problem to keep the name as is? Are we pressured to ship it or something?
cc @terrajobst @danmosemsft

[KrzysztofCwalina]

corfxlab was create to try ideas quickly as opposed to waiting for decisions. Is there any harm you see with renaming?

[karelz]

Would it cause harm if we use the same name from another repo in future? (when we move the code)
What is the value of the renaming now?

I guess that until the builds stay only on myget, we are kind of fine. I will be concerned when we start pushing the packages to nuget.org.

[KrzysztofCwalina]

The value is that @jamesqo could add his list to it, without the name being silly (implying its just multivaluedictionary).

corfxlab publishes to myget. If we want to push to nuget at some point, we can meet and discuss all the decisions we need to make before it happens.

I just don't want to block people writing code and trying things on lots of procedural decisions that have value for the shipping .NET Platform, but seem to be an overkill of quick things people want to try, prototype, incubate.

[karelz]

If you are sure it won't cause any harm in future if/when we decide to move the code to another repo and ship from there, then I don't care about renames.
I'd like to hear @terrajobst's thought on this ...

[danmoseley]

My take: for sure, move quickly in corefxlab, etc. Go for it. But if folks are putting work into there with the assumption it will go into corefx -- they may want to wait until we have decided whether we would take such a collections-pack so they aren't disappointed.

[KrzysztofCwalina]

Agreed

[joshfree]

I just don't want to block people writing code and trying things on lots of procedural decisions that have value for the shipping .NET Platform, but seem to be an overkill of quick things people want to try, prototype, incubate.

+1000

[Petermarcu]

How about "Advanced". You used the word in your description of what they were. Power seems odd. Are they for managing power consumption? :)

Please do go fast in corefxlab. Process overhead should be minimal. Code from corefxlab should never officially ship on NuGet. The code should be consumed into a shipping repo before it goes to NuGet. This is imperative in order to keep corefxlab as a go fast, playground.

[omariom]

PowerCollections is already a thing
https://powercollections.codeplex.com/

[jkotas]

is imperative in order to keep corefxlab as a go fast, playground.

You would be able to run even faster if the independent experiments are in its own repos.

The code should be consumed into a shipping repo

One problem with this is that you will lose all the history behind the code, unless you go through the pain of pruning and replying the history that nobody does. If you start with independent experiments in independent repos, you can officially ship from that same repo if the experiment becomes viable.

[jamesqo]

@jkotas

You would be able to run even faster if the independent experiments are in its own repos.

I think it would be easier for discoverability if the projects were hosted in corefxlab.

[jkotas]

For discoverability, corefxlab can have a page of related experimental projects done by other people. The projects do not have to be physically hosted there.

[jamesqo]

@jkotas OK. So only types that are fated to eventually make it into the framework (like Span<T>) should be in corefxlab, you're saying?

[jkotas]

From https://github.com/dotnet/corefxlab

This repo is for experimentation and exploring new ideas that may or may not make it into the main corefx repo. While this repo is meant for experimentation, we still want to focus our efforts in a particular direction, specifically to work on areas aligned with our roadmap.

In practice, it means that the stuff that is not on the roadmap won't get attention. You can see it playing out in corefxlab today: There are number of projects living on corefxlab that are not on the current roadmap. The activity on them is near zero.

[danmoseley]

this was done.