Topic: Find a good and non-confusing home for the remaining monolith

[mlaventure]

Sounds perfect, it feels like you self-nominated for the task, do you mind taking care of it?

[shykes2]

Any update on this?

At this point I think we should go for simplicity:

1. Rename moby/moby to moby/name-of-monolith with careful preparation and help from Github support. Assuming the logistical headaches are acceptable and carefully managed, I am OK with moving the stars & issues there. As we already pointed out, issue triage will be needed anyway.

2. Rename moby/tool to moby/moby

3. Move on to the next problem.

WDYT?

[cpuguy83]

SGTM.
If we can keep the docker/docker redirect alive (and pointing to the new repo) it would be helpful.

[vieux]

STGM as well. That’s what was our prefered solution while discussing with @tiborvass

@thaJeztah are taking care of contacting github to make sure the redirect will be handled properly (docker/docker -> moby/name-of-monolith)

[vieux]

and I propose moby/engine as name so we don’t have to introduce something new.

[mlaventure]

No sure how we handle voting, I liked the relevant post, but just to be sure; I’m on @shykes2 proposition and with engine being the name

[tiborvass]

One problem this brings is:

• All existing github.com/docker/docker URLs (for issues, PRs, commits) will break.
• All existing github.com/moby/moby URLs (for issues, PRs, commits) will break.

For the first one, it’d be great to have a way to have docker/docker redirect to moby/name-of-monolith
For the second one, in the scenario you are suggesting, I don’t see a solution.

However, if we decide not to rename moby/tool to moby/moby, then both of those problems disappear.

[ijc]

@tiborvass

• All existing GitHub - moby/moby: The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems URLs (for issues, PRs, commits) will break.

I think that is why @shykes said “with careful preparation and help from Github support”, we need them to redirect docker/docker to the new place instead.

@tiborvass

• All existing GitHub - moby/moby: The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems URLs (for issues, PRs, commits) will break.

We should be asking Github for their input on this, for all we know this is solvable somehow on their end.

[thaJeztah]

@mlaventure

No sure how we handle voting,

Looks like the “poll” plugin is installed;

[poll public=true]
- Yes
- No
- Maybe
[/poll]

Gives:

• Yes
• No
• Maybe

[thaJeztah]

@tiborvass

One problem this brings is:

• All existing GitHub - moby/moby: The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems URLs (for issues, PRs, commits) will break.
• All existing GitHub - moby/moby: The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems URLs (for issues, PRs, commits) will break.

For the first one, it’d be great to have a way to have docker/docker redirect to moby/name-of-monolith
For the second one, in the scenario you are suggesting, I don’t see a solution.

However, if we decide not to rename moby/tool to moby/moby, then both of those problems disappear.

FWIW, I sent an e-mail yesterday to someone at GitHub to see if we can get assistance with the move.
I haven’t heard back yet, but otherwise we’ll try to reach out to support. Possibly they can assist in doing
a migration, and setting up / modifying existing redirects.

[shykes2]

If github can’t help us in a satisfactory way, I’m ok as a plan B with
keeping moby/moby empty, and moving the tool to something like
moby/moby-cli or something like that.

[ehazlett]

sgtm with +1 to moby/engine and being able to redirect docker/docker -> moby/engine a bonus.

[stevvooe]

+1 for moby/engine. It is very natural.

[shykes2]

Warning: contrarian opinion incoming. Please bear with me.

• I agree that “engine” is familiar for contributors to Docker Engine who are now asked to continue their work in Moby. Keeping a familiar term is a good thing, it gives us a reference point for understanding how the new things relate to the old things. So: let’s use that word.

• But let’s not forget that the word “engine” alone does not obviously mean “Docker Engine” for the wider community beyond active open-source contributors (which are a small minority). Most people just call it “Docker” and are not familiar with the word “engine”. So: let’s not call the project just “Moby Engine”, because that would get simplified to just “Moby” by many people. This would cause ambiguity, and ambiguity is not our friend right now.

• I suggest calling our new engine MCE, which stands for Moby Container Engine. We active contributors can continue to call it “the engine” like before. The rest of the community will learn a new name that 1) is distinctive, 2) will not be confused with “Moby”, and 3) is still an engine.

We system nerds love acronyms. I bet you that MCE will catch on in no time.

Strawman pitch.

Q. What is MCE?
A. MCE, or Moby Container Engine, is the reference implementation of a core container engine based on Moby components. It is used as the core runtime of the Docker platform, and is a great base for creating custom container platforms without straying too far from the industry standard.

[vieux]

@stevvooe @ehazlett so how about moby/MCE ?

[stevvooe]

@vieux Acronyms tend to get used incorrectly and make it harder to learn a system. In this case, the expansion is moby/moby-container-engine, which is already redundant. For a long time, we have worked with an integration and apparatus called the engine. People will call it the engine, as it is more differentiated from the other parts of Moby, or the project itself. It would be nice to finally have a project named after what people actually call it.

“Where is the code for the engine? It is in the place called engine!”.

Unless we have plans for something else in moby to be called engine, we should stick with that terminology. The README should say “Moby Container Engine”. We can call it MCE (or McE or Mickey) in cases where it needs to be disambiguated. But I really like the simplicity of calling it moby/engine.

[ehazlett]

I think moby/mce would cause confusion as to what it is and since we would be moving what we know today as the “engine” I think it makes sense to call it engine.

[thaJeztah]

If the plan is to break the engine further apart (and it to eventually dissolve), then I’m -1 on giving it a fancy name; just “engine” would be fine.

If there’s plans to keep the “engine” around, we can think of better names, but (as @stevvooe mentioned); it’s known as the “engine”, so why name it anything else? (the engine not being a runtime is of course a separate topic).

[shykes2]

My concern with calling it just “engine” is that most people won’t call it engine: they’ll call it “Moby Engine” which will get shortened to “Moby”. Therefore calling it “engine” will perpetuate the confusion between the Moby Project and the monolith that is one component of the Moby Project.

[ijc]

A bit of a side point, but wrt to the repetitiveness of moby/moby-foo remember that this will be cloned into $user/moby-foo. It’s already a potential source of conflicts that I have ijc/cli as a fork of docker/cli, I would have preferred ijc/docker-cli even if docker/docker-cli is stuttery, likewise of ijc/tool (although that should be set to go away). Hopefully I will never need to contribute to some other cli project on GH. Anyway TL;DR, please try to consider the repo name in isolation from the org name.

WRT to the subject at hand, did we rule out moby/monolith? (of course I would prefer `moby/moby-monolith ;-)).