Sounds perfect, it feels like you self-nominated for the task, do you mind taking care of it?
Any update on this?
At this point I think we should go for simplicity:
moby/name-of-monolithwith 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.
Move on to the next problem.
If we can keep the docker/docker redirect alive (and pointing to the new repo) it would be helpful.
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 (
and I propose
moby/engine as name so we don’t have to introduce something new.
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
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.
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.
We should be asking Github for their input on this, for all we know this is solvable somehow on their end.
Looks like the “poll” plugin is installed;
[poll public=true] - Yes - No - Maybe [/poll]
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.
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.
sgtm with +1 to
moby/engine and being able to redirect
moby/engine a bonus.
moby/engine. It is very natural.
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.
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 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
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/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.
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).
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.
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 ;-)).