remove will not provide language placed on common distribution use cases #45
Conversation
Signed-off-by: Mike Brown <brownwm@us.ibm.com>
| * What: Specifying a distribution method | ||
| * In/Out/Future: In scope | ||
| * Status: In progress (see opencontainers/distribution-spec) | ||
| * Description: Define a protocol for image, manifest, config, and blob creation, retrieval, and deletion. | ||
| Listing repositories is a multi-repository action, which is out of scope for this entry. | ||
| Creating and deleting repositories are per-repository actions, which are out of scope for this entry. | ||
| Listing images within repositories is a per-repository action, which is out of scope for this entry. |
There was a problem hiding this comment.
I'd rather keep these limits to ensure we stay focused on push/pull for images and more granular objects. If the OCI wants to cover content-management at the repository level, that's fine with me, but I'd like it to be clearly separated from distribution so implementations could be compliant distribution engines without needing to implement repository-level operations. However, I'm happy to take that distinction up with the coming distribution maintainers if the TOB wants to punt on it by removing these lines here. More discussion in this vein in #37 and #44.
There was a problem hiding this comment.
Just as enabling content-management is not the same as providing content-management, I don't think providing a list of contents to enable certain push and pull workflows is the same as "covering content-management."
Per the discussions over on 44.. If there's a phrasing you want to add to ensure the resulting spec delineates MUST items necessary to certain primary workflows and further delineates as OPTIONAL the portions of the spec not necessary for the primary workflows, that works for me.
|
Closed in lieu of #46 |
There's no need to use absolute links for these. And using relative links sets a good example for future proposals, because the links will work in the proposal branch's README before the referenced proposal lands in the TOB master. There's a similar absolute link for the code-of-conduct in the distribution proposal. I haven't touched that though, since the intention may have been to show the absolute URL which would be included in new project's repository. I don't think that matters though, because the project template has included a similar link since opencontainers/project-template@ee72bc89 (CONTRIBUTING: Code of conduct, meetings, mailing list, and IRC, 2016-09-08, opencontainers#45). Signed-off-by: W. Trevor King <wking@tremily.us>
There's no need to use absolute links for these. And using relative links sets a good example for future proposals, because the links will work in the proposal branch's README before the referenced proposal lands in the TOB master. There's a similar absolute link for the code-of-conduct in the distribution proposal. The intention may have been to show the absolute URL which would be included in new project's repository. I don't think that matters, because the project template has included a similar link since opencontainers/project-template@ee72bc89 (CONTRIBUTING: Code of conduct, meetings, mailing list, and IRC, 2016-09-08, opencontainers#45), so I've left that alone here. Signed-off-by: W. Trevor King <wking@tremily.us>
This commit removes a few of the restrictions placed on the distribution method proposed in #35. For example, the maintainers should have the freedom to explore adding image listing protocols to go along with the protocols for image, manifest, config, and blob creation, retrieval, and deletion.
Signed-off-by: Mike Brown brownwm@us.ibm.com