project: expand the umbrella of containerd

[stevvooe]

There are several projects that are dependencies of containerd that are without an official home. These tend to be critical but maintained under one of several personal github handles. We'd like these projects to be officially maintained as part of the containerd project so they get the attention needed to ensure a healthy dependency tree in containerd.

Under this proposal, the following projects would be moved into the containerd org:

• https://github.com/crosbymichael/go-runc -> https://github.com/containerd/go-runc
• https://github.com/crosbymichael/cgroups -> https://github.com/containerd/cgroups
• https://github.com/crosbymichael/console -> https://github.com/containerd/console
• https://github.com/stevvooe/go-btrfs -> https://github.com/containerd/btrfs
• https://github.com/stevvooe/continuity -> https://github.com/containerd/continuity
• https://github.com/tonistiigi/fifo -> https://github.com/containerd/fifo

If there are any questions, commentary, suggestions or objections, please let us know.

This motion has been approved by the following maintainers:

• @crosbymichael
• @dqminh
• @dmcgowan
• @estesp
• @hqhq
• @jhowardmsft
• @mlaventure
• @stevvooe

@containerd/containerd-maintainers PTAL

[crosbymichael]

Our idea for maintaining these projects is that if you are a containerd maintainer, you are a maintainer of all projects in the org because they all fit together.

I think it is better to have a single group of maintainers that all share the same goals and think of the project and its dependencies as a whole verses individual maintainers for each repo.

What do you all think? We can have the maintainer files in each of the projects point back to the main MAINTAINERS file that is found in this repo, containerd/containerd. It makes it simple and ensures we all share the load of keeping our dependencies at the same standards of quality as our main repo.

[mlaventure]

Why btrfs and not go-btrfs after the move?

Otherwise, no objections on my side, @crosbymichael explanation makes sense to me.

[stevvooe]

Why btrfs and not go-btrfs after the move?

Just style. 😎

Also, we may want to add some tools in there for working with btrfs.

[caniszczyk]

LGTM, I would recommend that new projects get approved by the existing set of MAINTAINERS, simply voting or building consensus in an issue like this should be sufficient.

I'd propose adding a "[Rules.adding-projects]" section to https://github.com/containerd/containerd/blob/master/MAINTAINERS that clarifies how new projects get added (or potentially archived down the road).

[stevvooe]

LGTM

@containerd/containerd-maintainers Please LGTM this issue and I'll mark the check box accordingly.

@caniszczyk Do you mind proposing some language for addition into the MAINTAINERS file?

[mlaventure]

LGTM

[caniszczyk]

@stevvooe np, will put it on my queue #773

[dmcgowan]

LGTM

[estesp]

LGTM

[crosbymichael]

There is no rush also, we can give this time to make sure the maintainers and community have a chance to look at this proposal. I'll include this in Friday's dev report.

[lowenna]

LGTM

[stevvooe]

There is no rush also, we can give this time to make sure the maintainers and community have a chance to look at this proposal. I'll include this in Friday's dev report.

Sounds reasonable. We can let this breath until next week.

[hqhq]

LGTM

[justincormack]

I guess the other option is to merge these into the main containerd/containerd repo. I have no preference, but consolidating SGTM.

[ijc]

Why btrfs and not go-btrfs after the move?

Just style. 😎

@stevvooe go-runc was carried over as is without dropping the go-. Not sure if that was intentional.

[dqminh]

LGTM

[crosbymichael]

@ijc25 ya, that is because there is already a runc project and I had to name the CLI bindings go-runc because I have an existing runc fork. I guess with the new org, i don't think we will have any runc forks so we could change the name as well.

[stevvooe]

At this point, we are pretty unanimous. We'll leave this open for community commentary and perform the moves next week!

Exciting!

[ibuildthecloud]

Any thought on the pkg convention. I'm not totally sure what the conventions really means, but I have always liked that in github.com/docker/docker/pkg that means that those things are pretty much isolated utilities and not really docker dependent code.

[stevvooe]

Any thought on the pkg convention.

I'm not a huge fan of the pkg convention. In practice, the code coming out of there (in docker) wasn't more stable or better for cross project reuse. We still had to do some refactoring to bring parts into containerd. There are also problems with vendoring the entirety of docker, which may not be a problem for containerd downstreams. Typically, the separate projects do allow for better separation, interface-forward design and easier reuse but there are definitely drawbacks. Either way, these were already pieces that we had broken out for some reason or another, so hopefully they have been vetted as broadly useful.

Are there any examples that you think don't belong?

[stevvooe]

@crosbymichael Was fifo transferred?

[crosbymichael]

@stevvooe yes, what you talking about