Skip to content
This repository has been archived by the owner on Jul 18, 2023. It is now read-only.

Adding external implementations #59

Closed
wants to merge 2 commits into from
Closed

Adding external implementations #59

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6750177
Adding external implementations
sudo-bmitch Jul 7, 2022
77dcd70
Distinguishing OCI WG from projects in other orgs
sudo-bmitch Jul 8, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 16 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,8 +34,17 @@ The current state of the [OCI Artifacts][oci-artifacts] repository:

## Related Projects Working on Extending OCI Specs

- [OCI Reference Type Working Group][oci-reftype-wg]
- [CNCF ORAS Artifacts Spec][oras-artifacts]
[OCI Reference Type Working Group][oci-reftype-wg]

Other projects:

- [Docker buildkit][buildkit]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's sorted by the link.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The link isn't what people see.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also help understand why this list is added to the readme.md as opposed to implementations

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

another .md page would be warranted if it gets tldr

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

- [OpenSSF sigstore/cosign][cosign]
- [Google go-containerregistry/crane][crane]
- [CNCF distribution][distribution]
- [CNCF ORAS Artifacts Spec][oras-artifacts]
- [regclient][regclient]
- [zot][zot]

## Project Governance and License

Expand Down Expand Up @@ -70,7 +79,10 @@ Artifacts will reference specific [distribution][distribution-spec], [index][ima
A: No. Artifacts are a prescriptive means of storing [index][image-index] and [manifest][image-manifest] within [distribution][distribution-spec] implementations.

[artifact-authors]: ./artifact-authors.md
[buildkit]: https://github.com/moby/buildkit
[code-of-conduct]: https://github.com/opencontainers/.github/blob/master/CODE_OF_CONDUCT.md
[cosign]: https://github.com/sigstore/cosign
[crane]: https://github.com/google/go-containerregistry/tree/main/cmd/crane
[distribution]: https://github.com/distribution/distribution
[distribution-spec]: https://github.com/opencontainers/distribution-spec/
[image-index]: https://github.com/opencontainers/image-spec/blob/main/image-index.md
Expand All @@ -79,4 +91,6 @@ A: No. Artifacts are a prescriptive means of storing [index][image-index] and [
[oci-image-v101]: https://github.com/opencontainers/image-spec/releases/tag/v1.0.1
[oci-reftype-wg]: https://github.com/opencontainers/wg-reference-types/
[oras-artifacts]: https://github.com/oras-project/artifacts-spec/
[regclient]: https://github.com/regclient/regclient/
[singularity]: https://github.com/sylabs/singularity
[zot]: https://github.com/project-zot/zot