opencontainers / artifacts

OCI Artifacts
https://opencontainers.org
Apache License 2.0
224 stars 54 forks source link

Adding external implementations #59

Closed sudo-bmitch closed 1 year ago

sudo-bmitch commented 2 years ago

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

sudo-bmitch commented 2 years ago

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

mikebrow commented 2 years ago

I'd like to distinguish that the WG is a project created under the OCI organization

ok?

specifically for the purpose of extending the spec. However I'm hearing there are differing opinions there.

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.

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.

Separately makes sense, it's own section or add a "-----" break line works?

And should there be any wording that describes how the WG is different from the other projects.

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?

sudo-bmitch commented 2 years ago

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.

mikebrow commented 2 years ago

.. sry about fat fingering your comment ^

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.

absolutely..

For the coming soon part we could add a section for "announcements..."

rchincha commented 2 years ago

Similar to the distribution-spec, does it also make sense to add a conformance test when ready to cut a spec release?

sudo-bmitch commented 2 years ago

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.

mikebrow commented 2 years ago

Similar to the distribution-spec, does it also make sense to add a conformance test when ready to cut a spec release?

Yes, OCI has tried to do conformance for each spec and reference implementation.

sudo-bmitch commented 2 years ago

@opencontainers/artifacts-maintainers PTAL.

mikebrow commented 1 year ago

Artifacts mission is moving to opencontainers/image-spec this repo is being archived, as such this PR will go read only soon.