New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[META] Splitting moby and docker #32867

Open
vieux opened this Issue Apr 27, 2017 · 17 comments

Comments

Projects
None yet
8 participants
@vieux
Copy link
Collaborator

vieux commented Apr 27, 2017

See #32691 for context.

We want to split moby and docker, here is a WIP list of tasks.

  • Find a good an non-confusing home for the remaining monolith #32871
  • Add the Moby tool to moby/moby #32859
  • Create a place for async community communication #32861
  • Setup a short url for go pkgs #32862
  • Update contributing guidelines #32863
  • Use the new Docker CLI located at github.com/docker/cli #32694
  • Issues cleanup #32864
  • Setup weekly reports #32865
  • Define a plan for HTTP engine API #32873
  • Update integration-cli tests #32866
  • Add better getting started to mobyproject.org #32869
  • Split up the monolith #32872
  • Update references of dockerproject.org #32860
  • Find a place for /pkg #32989

Again the list is in progress, please use the comments to suggest any missing item.

@vieux vieux added the area/project label Apr 27, 2017

@vieux vieux added this to the splitting_moby_and_docker milestone Apr 27, 2017

@shykes

This comment has been minimized.

Copy link
Collaborator

shykes commented Apr 27, 2017

Thanks @vieux great start,

Also:

  • find a good an non-confusing home for the remaining monolith while we split it.

  • split up the monolith

@shykes

This comment has been minimized.

Copy link
Collaborator

shykes commented Apr 27, 2017

Also: define a plan for HTTP engine API.

@AkihiroSuda

This comment has been minimized.

Copy link
Member

AkihiroSuda commented Apr 27, 2017

how to report security issues and who/how triages them

@vieux

This comment has been minimized.

Copy link
Collaborator Author

vieux commented Apr 27, 2017

@shykes added your suggestions

@AkihiroSuda are you talking about the whole CVE process ?

@AkihiroSuda

This comment has been minimized.

Copy link
Member

AkihiroSuda commented Apr 27, 2017

@vieux

What I meant was that we would need equivalent of security AT docker DOT com (Or just reuse that address for Moby).
It would contain CVE process as well.

@mlaventure

This comment has been minimized.

Copy link
Contributor

mlaventure commented Apr 27, 2017

Does defining a plan for the HTTP engine API also include defining one for standard inter-component communication?

Also I created a project to more easily find the associated tasks (rather than having to bookmark this one): https://github.com/moby/moby/projects/6

@duglin

This comment has been minimized.

Copy link
Contributor

duglin commented Apr 27, 2017

While it might be nice for the component-level interactions, I'm more concerned with the API exposed to the user, so I would put the engine-like API at the top on the list and the other stuff in a "investigate" or "consider for later" category.

@dnephin

This comment has been minimized.

Copy link
Member

dnephin commented Apr 27, 2017

@mlaventure I think inter-component communication is one of the bigger blockers for "split up the monolith" (#32872 (comment)). It might make sense to track those dependencies in #32872

@mlaventure

This comment has been minimized.

Copy link
Contributor

mlaventure commented Apr 27, 2017

@duglin I agree that the engine API has priority, I was just wondering where the other one were tracked.

I'm fine with tracking them with #32872 as @dnephin suggested, it does make sense.

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented Apr 27, 2017

@vieux I think a similar option to security@docker.com, but then for the moby project (e.g. security@mobyproject.org)

@rogersachan

This comment has been minimized.

Copy link

rogersachan commented Apr 29, 2017

@vieux
image

This is the image I got in my inbox regarding the docker split. It should be noted that docker still has ownership of swarmkit, infrakit, notary, distribution, libnetwork, and compose. Are these supposed to be transferred over to moby or will these actually become part of Docker CE/EE?

@shykes

This comment has been minimized.

Copy link
Collaborator

shykes commented Apr 29, 2017

@rogersachan Moby does not aspire to "own" any other projects. We are using it as a temporary staging area for projects preparing to be spun-out as fully autonomous projects.

For the projects you list: we plan to spin these all out as standalone projects. They will neither be part of Moby nor Docker CE - but they will be upstream from both.

@rogersachan

This comment has been minimized.

Copy link

rogersachan commented Apr 30, 2017

So swarmkit, infrakit, notary, distribution, libnetwork, vpnkit, datakit, hyperkit, and compose will all eventually be removed from the moby and docker orgs? @shykes

@thaJeztah thaJeztah added the roadmap label May 3, 2017

@AkihiroSuda

This comment has been minimized.

Copy link
Member

AkihiroSuda commented Nov 8, 2017

What should we do with CHANGELOG.md?

Do we want to just remove that file or keep maintaining that file (but without version)?
My opinion is the latter.

Also, do we want to deprecate weekly reports?
The moby project blog looks like the successor now.

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented Nov 8, 2017

I suggested doing a weekly changelog (https://forums.mobyproject.org/t/proposal-create-weekly-change-logs/76), but possibly there will be weekly(?) releases. Starting with a fresh changelog would likely make sense though.

@AkihiroSuda

This comment has been minimized.

Copy link
Member

AkihiroSuda commented Nov 8, 2017

Weekly changelog SGTM, but I think we are very likely to fail creating weekly changelogs unless the workflow is completely automated.
So the first step might be extending poule 😄

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented Nov 8, 2017

Yes, I was playing with https://github.com/skywinder/github-changelog-generator/ a while back, but possibly the "release" code from containerd (https://github.com/containerd/containerd/tree/master/cmd/containerd-release) would work (or can be used as a starting point). Ideally, such a tool would take the impact/xx labels into account to group changes into categories.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment