Proposal: OCI Tools repo?

[jdolitsky]

I've been thinking a bit about umoci and ORAS proposals (#67 and #68) - how do people feel about some generic new repo like opencontainers/tools which could contain a collection of various tools enabling OCI-related work?

Some initial tools we can include:

• umoci: Modifies Open Container images (https://github.com/openSUSE/umoci)
• ORAS: OCI Registry as Storage (https://github.com/deislabs/oras)
• Reggie: Simple Go HTTP client for OCI Distribution (https://github.com/bloodorangeio/reggie)

This repo can have its own criteria for which tools should be added vs. going through the TOB. This reduces the burden on TOB for "blessing" certain tools, while these tools still benefit from being under the opencontainers namespace.

We could organize it using top-level directories in the repo corresponding to the tool, for example:

|____tools/
| |____oras
| | |____README.md
| | |____<oras_source>
| |____reggie
| | |____README.md
| | |____<reggie_source>
| |____umoci
| | |____README.md
| | |____<umoci_source>

This introduces some challenges around the release process and how maintainers operate, but perhaps it's the best approach all things considered. I'm imagining the repo adopting several other tools people would be willing to contribute. It may also serve as a new home for other repos like go-digest, runtime-tools, and image-tools.

Thoughts? Happy to help organize and maintain a repo like this.

[cyphar]

We are going to have a vote on the umoci and ORAS proposals next week. The reason for the (significant) delay is that it was unclear whether under the OCI Charter we are actually allowed to include projects that are "tools" (and there were also disagreements about whether we should include such projects) -- despite runc's inclusion in the OCI which is all-but-hard-coded into the Charter as a foundational OCI project. This has culminated in #76 as well as lots of discussions of reforming the OCI Charter to better describe the current state of the OCI -- I'm currently working on a draft for that.

In my view, a hodge-podge repo will have even more trouble because it'd introduce a different kind of "inclusion" into the OCI which is on even shakier ground when it comes to the Charter (as well as whether it's something the TOB should accept even if it is allowed under the Charter).

Additionally if the purpose of the hodge-podge repo would be to provide a way for folks to become aware of projects in the OCI space, then I feel it'd also be redundant. All three of the OCI specifications have an "implementations" section that contains a list of known implementations of the specification. I don't see a hodge-podge repo giving projects any more legitimacy than listing them as example implementations in the relevant specification, but it does murky the waters of what is an OCI project.

I also really don't like the idea of intertwining the repo history of totally different projects, and as a maintainer of quite a few projects (including umoci) I probably would be against including my projects in such a scheme purely because it means other people have commit access to a project without being maintainers.

[jdolitsky]

@cyphar thanks for the context - makes sense. I agree with your points about this making commit history and ownership more difficult.

I'll leave this open for a week or so and close if I dont hear from others.

[jdolitsky]

Looks like vote open for umoci and oras, will close this