bmitch3020 https://forums.mobyproject.org/u/bmitch3020
May 12
Solomon_Hykes:
There are also arguments in favor of keeping it in place. Some of these
arguments are:
- We want to split up the engine into distinct components, so eventually
(let’s say within 9-12 months) that repository would go away.
For this, I’d say renaming to a final location now would lessen any pain
9-12 months from now when whatever is left gets renamed to
$gRPC_multiplexer_project_name. If we can find a good name for that 12
month move now, that would be even better for keeping the issues, pr’s etc,
with the engine code. If not, at that 12 month point, 95% of those issues
will need to move to another project, but they’ll be in a single repo to
sort through rather than intermixed with everything in the moby tool repo.
The only way to avoid an issue migration would be to rename the current
moby/moby to the new monolith repo, right? But that would cause more
rename headaches.
So we need to choose from two ways to create a new monolith repo:
Option 1: rename. Pro: no issue migration. Con: rename headaches.
Option 2: create fresh. Pro: no rename headaches. Con: issue migration (but
not intermixed with moby tool issues as you say).
I think I prefer option 2. Issue migration is less painful than renaming.
And those issues need a serious manual sort anyway. So we will pay that
cost regardless.
- We need to create one more name for a thing, in a time where there
are
lots of new things with lots of new names.
I’m less confused by lots of new names. Reusing the same name for multiple
things is what confuses me. See this blog post from me
https://boxboat.com/2017/05/12/moby-inception/ for a little more
background. The new name could be something like moby/ce or moby/engine and
make more sense to those not familiar with moby.
I agree that creating a new name is much easier than redefining an existing
name.
- We very recently moved docker/docker to moby/moby, which was a
disruption
to contributors. Another move so shortly afterwards could make things
worse.
I completely understand. We can’t undo what happened before so I’m going
to take the economics view of a sunk cost. Without considering the past,
starting from where we are today, what’s the best option? The only
additional thing I’d recommend is putting out a post saying “in 5 days,
we’re moving moby/moby to it’s final home xyz” so it’s not a surprise.
Before anything, the most urgent is to switch to facade URLs for go
packages. We can do this right now. Tibor, Victor: what’s the status on
that? As soon as facade URLs are in place everywhere, the number of
affected repos will stop growing.
Then, yes, we should clearly announce that 1) facade URLs are the
recommended official way to consume, available now; and 2) there is a X
days grace period before the old URLs are disabled.
- Because there is confusion between “Docker platform” and “Docker
container engine”, this new repo might be interpreted as “Docker
platform
without the brand”, which implies a promise of feature parity and
interface
compatibility with Docker… a promise we don’t want to make. I also
worry
that a well-intentioned distro packager will understand the engine
repo as
a drop-in replacement for the docker package… Which would be a
mistake.
As long as we don’t call it moby/docker-ce, I think the only other thing
to do is to have a good readme that lays out exactly what you just said.
It’s certainly a point I was missing before now.
I agree. Victor: can you add this to the task list?
My favorite option is to create a new repository for the engine monoith,
with a fresh new name, and start the migration process as described here
ASAP.
I have an idea for a name 
Thoughts?