Adding external implementations #59
Conversation
sudo-bmitch
requested review from
dmcgowan,
josephschorr,
mikebrow,
SteveLasker and
stevvooe
as code owners
sudo-bmitch
force-pushed
the
pr-external-implementations
branch
2 times, most recently
from
8d57899 to
92a2512
Compare
Signed-off-by: Brandon Mitchell <git@bmitch.net>
sudo-bmitch
force-pushed
the
pr-external-implementations
branch
from
92a2512 to
6750177
Compare
|
(@mikebrow adding my reply here for a bit more visibility.) I'd like to distinguish that the WG is a project created under the OCI organization specifically for the purpose of extending the spec. However I'm hearing there are differing opinions there. So I'll open it up to the greater community to say whether the WG should be listed separately, at the top, or intermixed with the projects added here. And should there be any wording that describes how the WG is different from the other projects. |
ok?
Extending the spec, yes. Details here the purpose, scope, and intended work product of the wg Skimming, I see use case documents; a "reference implementation" for the chosen "reference types proposal;" a "Referrers API specification" to "sit within or along side the Distribution specification;" documentation regarding "the pros and cons for versioning the existing manifests, compared with creating a new manifest to support reference types;" and a "Proposal to extend existing manifests or create a new manifest to support reference types." That's a lot of stuff! A lot of content we'll want to use here in this project. If you like ^ there's a more detailed description/list we could use here to describe what's behind the wg link.
Separately makes sense, it's own section or add a "-----" break line works?
I suppose we could/should say something about the wg receiving input from these other projects, the dates the projects started, some project status(though that would need frequent updates), project governance and licensing is different but similar, ... Is that what you are thinking? |
|
As a visitor to the page, I think it would be useful to distinguish that the WG is under the OCI GitHub repo, and the rest are external repositories with their own goals, governance, etc. A lot of pages will flag links where you are leaving their site so it feels useful to me to have either a section heading for the external repos or a highlight for the WG entry. It also feels like OCI should be directing visitors to work with the working group to influence changes that are likely to be recommended to the TOB soon. |
|
.. sry about fat fingering your comment ^
absolutely.. For the coming soon part we could add a section for "announcements..." |
Signed-off-by: Brandon Mitchell <git@bmitch.net>
|
Similar to the distribution-spec, does it also make sense to add a conformance test when ready to cut a spec release? |
I think that gets into the output of the working group and what the TOB does with it. My best guess of that is we'll have updates to distribution-spec and updates to the conformance tests there. We don't really have conformance tests for clients and the json, but that would be interesting to consider for the future. |
Yes, OCI has tried to do conformance for each spec and reference implementation. |
|
@opencontainers/artifacts-maintainers PTAL. |
|
|
||
| Other projects: | ||
|
|
||
| - [Docker buildkit][buildkit] |
There was a problem hiding this comment.
@sudo-bmitch, can you help us understand the ordering of the displayed list?
If you alpha sort the displayed values, wouldn't it be:
CNCF distribution
CNCF ORAS Artifacts Spec
Docker buildkit
Google go-containerregistry/crane
OpenSSF sigstore/cosign
regclient
zot
There was a problem hiding this comment.
The link isn't what people see.
There was a problem hiding this comment.
True, but it feels weird to change the order when something gets donated, like Docker Distribution to CNCF Distribution. Do we need to strip off the parent orgs to reduce confusion? I usually just call it Kubernetes and not CNCF Kubernetes.
There was a problem hiding this comment.
Can you also help understand why this list is added to the readme.md as opposed to implementations
There was a problem hiding this comment.
was why I was asking for a description regarding reason for link here.. a brief comment relating what each project may be doing, normally from the project owners if they would comment and/or approve the mention
There was a problem hiding this comment.
another .md page would be warranted if it gets tldr
There was a problem hiding this comment.
i'm fine either way, starting here and updating in a follow up or add just enough explanation here.. to make alpha order obvious I guess just show the string being used..
There was a problem hiding this comment.
While we're adding things, might as well also add ko since it attaches SBOMs to images by default, using the same mechanism as cosign.
As a contributor to cosign, and maintainer of crane and ko, if we think we need a little text blurb, I can propose:
- [cosign][cosign] supports attaching signatures, SBOMs and attestations to images in a manner supported by [many registry implementations](https://github.com/sigstore/cosign#registry-support)
- [crane][crane] supports modifying and moving artifacts between supported registry implementations
- [ko][ko] supports building images for Go applications, including attaching SBOMs using cosign's implementation
There was a problem hiding this comment.
If we don't have a statement from the project owner, should we remove them from the above list? My goal was to be inclusive without triggering a debate over wording of a description that would delay this getting merged.
What specific changes are being requested that would result in the project maintainers approving and merging this?
|
Artifacts mission is moving to opencontainers/image-spec this repo is being archived, as such this PR will go read only soon. |
From the discussion in #56, here's a list of external projects I'm aware of. Feel free to add any that I've missed.
Signed-off-by: Brandon Mitchell git@bmitch.net