docker-machine is closed, so if we want it to continue, we need to start releasing

[SvenDowideit]

see docker#4537

I'm also wondering if toolbox is needed too - there are users that don't use hyper-v, or simply have different goals :/

[gbraad]

At the moment machine is more important to us... and not even in binary form (we only compile and link to the library; same for minikube)

@praveenkumar @LalatenduMohanty @dlorenc @aaron-prindle @r2d4 WDYT?

[LalatenduMohanty]

At this moment docker machine as library is important for us. May be we can release the binary too (in future if we get some new features).

[gbraad]

at the origin's repo they only used:

• circleci
• appveyor
• travis-ci

which is easy to replicate.

[gbraad]

ALso, should this remain a fork... or should we break this reference and re-import as a 'new' project?

[praveenkumar]

At the moment machine is more important to us... and not even in binary form (we only compile and link to the library; same for minikube)

Right for us (minishift + minikube) are going to use as library but if they are closing the project down then might be in future we need to build binary out of it also.

[gbraad]

to use Circle CI for macOS we need to send an email, and for AppVeyor we need a dedicated account

[gbraad]

@praveenkumar it depends. do we really want to use a *-machine command to control the state of... eh, what? We do not really integrate well with the machine environment at all, as a create using this tool does not use our specific provisioners. To make it even work together, you need to do: kubernetes/minikube#2681

[afbjorklund]

Seems like continuing Docker Machine and Docker Toolbox is a huge task, if not even Docker Inc. wants to do it... Better focus on libmachine, perhaps even in a separate git repository (like with the kvm2 driver) ?

• github.com/docker/machine/commands/mcndirs
• github.com/docker/machine/drivers
• github.com/docker/machine/libmachine
• github.com/docker/machine/version

Like it says, that mcndirs should probably be removed:

vendor/github.com/docker/machine/libmachine/provision/boot2docker.go:	// TODO: Ideally, we should not read from mcndirs directory at all.
vendor/github.com/docker/machine/libmachine/provision/boot2docker.go:	b2dutils := mcnutils.NewB2dUtils(mcndirs.GetBaseDir())

And the drivers are handled a bit differently, by minikube...

[gbraad]

libmachine is already forked and has been setup for CI

…

On Mon, Jul 30, 2018 at 10:13 PM, Anders Björklund ***@***.*** > wrote: Seems like continuing Docker Machine and Docker Toolbox is a huge task, if not even Docker Inc. wants to do it... Better focus on *libmachine*, perhaps even in a separate git repository (like with the *kvm2* driver) ? - github.com/docker/machine/commands/mcndirs - *github.com/docker/machine/drivers <http://github.com/docker/machine/drivers>* - *github.com/docker/machine/libmachine <http://github.com/docker/machine/libmachine>* - github.com/docker/machine/version Like it says, that *mcndirs* should probably be removed: vendor/github.com/docker/machine/libmachine/provision/boot2docker.go: // TODO: Ideally, we should not read from mcndirs directory at all. vendor/github.com/docker/machine/libmachine/provision/boot2docker.go: b2dutils := mcnutils.NewB2dUtils(mcndirs.GetBaseDir()) And the drivers are handled a bit differently, by minikube... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAHZhjFcpS0bGGufZoyGHvKqrNesYWPks5uLxSTgaJpZM4VQc61> .

-- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ]

[afbjorklund]

@gbraad : also including the commands and everything, right ? (i.e. this repo)

[gbraad]

What do you mean with commands? We are unlikely to release a binary (app) from this repo.

[afbjorklund]

Ah, right. I thought that @SvenDowideit suggested doing just that (making new releases of docker-machine, and even the rest of the toolbox too ?)... But that minikube only needs libmachine (and mcndirs and version, per above).

Which means that theoretically it could use a different "libmachine-only" version of the repository, without the commands and without the cloud drivers. That would make it more of a outright fork, then just continuing hosting the old repository.

[gbraad]

right, we could create a new binary, but it would like have to be under a new name, like 'container-machine', plus removal of all the trademarks and mention of Docker. We will discuss this soon with Minikube; @praveenkumar might be able to invite you too

[SvenDowideit]

tbh, I was thinking that we'd just call it machine - but its been quite a long time since I actually used machine

[gbraad]

I am fine either way... for me it is about continued maintenance and possibly some refactoring.

[afbjorklund]

It seems like the v0.15.0 tag is missing from this repo ?
https://github.com/machine-drivers/machine/releases/tag/v0.15.0

Not sure if the changes to the PR template are desired ?
4f225c9

Thank you for your interest in contributing to Docker Machine!
Please note that the project is now in MAINTENANCE MODE, meaning we will
no longer review or merge PRs that introduce new features, drivers or
provisioners. We will continue to consider and review proposed bug fixes
and dependency upgrades when appropriate.

Thank you for your understanding.

---

But it would be nice to make things clear about support level, if it is "only" libmachine and drivers ?

There is already quite a difference in Docker versions, between boot2docker and minikube/minishift.

[dlorenc]

What did we decide here? I think we should probably drop the releases and binaries and make it clear that this is only about supporting libmachine and drivers.

[afbjorklund]

@dlorenc : I think that makes sense, and it seems like Docker will still maintain the old binaries for people who want their "legacy" solution (don't run Win or Mac)...

Do you need to actually change something in this repository, or is it just making it clear in the README or something - that is only intended as a library dependency ?

[dlorenc]

I'd like to make it clear in the readme, close this issue and then potentially delete the code/deps we no longer need.

[afbjorklund]

Did a short list previously (above), it looked straight-forward - except for that "mcnutils" thingie.

It could potentially be a future problem, if people want to use the drivers provided by this repository for the original machine implementation (docker) that is "frozen" in specificaiton if the library implemention (machine-drivers) drifts away from that by adding features or continuing to evolve. But right now, it's "close enough" that they should probably work for both ? There's already a selection of ISO images...

[dlorenc]

Yeah changing the interface will be troublesome. Your proposal of what to delete makes a lot of sense.

[dlorenc]

ALso, should this remain a fork... or should we break this reference and re-import as a 'new' project?

I think this makes sense - any idea how to break the reference?

[afbjorklund]

@SvenDowideit :
The upstream project is once again making some releases, and there are currently no commits here that aren't also merged there... So maybe it should just be rebased, and synced with the upstream 'master' ?

There are no changes (compared to v0.16.1) to the API, only to the bundled drivers themselves...
Currently the machine-drivers/master is in sync with docker/v0.16.0^, with only one backported commit.

[afbjorklund]

Leaving this at v0.16.1 (now with two backported commits)