[META] Splitting moby and docker

[vieux]

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.

[shykes]

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]

Also: define a plan for HTTP engine API.

[AkihiroSuda]

how to report security issues and who/how triages them

[vieux]

@shykes added your suggestions

@AkihiroSuda are you talking about the whole CVE process ?

[AkihiroSuda]

@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]

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]

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]

@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]

@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]

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

[rogersachan]

@vieux

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]

@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]

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

[AkihiroSuda]

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]

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]

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]

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.