Vote: Archive the artifacts repo

[jdolitsky]

The upcoming spec changes address the question of artifacts. The following repo served us well at the time, but now can only cause confusion for people new to OCI: https://github.com/opencontainers/artifacts

for more info see opencontainers/artifacts#63

I'll call the vote for @opencontainers/tob. Please approve, request changes, reply with LGTM, or not (and hopefully say why!).

• @sudo-bmitch
• @vbatts
• @jdolitsky
• @estesp
• @jonjohnsonjr
• @nishakm
• @samuelkarp
• @dmcgowan
• @cyphar

A 2/3 approval is required here, so 6/9 of the TOB members must approve.

[jdolitsky]

@opencontainers/tob PTAL

[sudo-bmitch]

LGTM with the assumption that we update the readme with a pointer to the image-spec guidance.

[samuelkarp]

Can we update the readme first? It'd be nice for the vote here to cover one action (archival), not multiple (archival + not-fully-specified readme updates).

[jdolitsky]

Just opened opencontainers/artifacts#67 to address the README

[SteveLasker]

I'm supportive of unifying the content across the specs, as this was the goal of image-spec/pull #770: Artifact spec additions and distribution-spec/pull #65, starting way back in March of 2019.

As a result, there was an OCI TOB Vote to create the artifacts repo, which included:

• Create a new artifacts repository, named github.com/opencontainers/artifacts
• Update the OCI distribution-spec to generically reference OCI manifest and OCI index, with OCI Image as one of many artifact types it can store.
• Update the OCI image-spec to reference images as an implementation of artifacts, using OCI manifest and OCI index

With broad adoption of OCI Artifacts and the evolution of artifacts/pull: OCI artifact manifest, Phase 1-Reference Types #29, we are getting closer to achieving the goal for leveraging the investments users, cloud providers and ISVs have in their registries. Enabling artifact authors to distribute new types, without having to create yet more package managers helps the community quickly innovate new ideas.

To complete the effort, and archive the artifact repo, the TOB may want to consider addressing the charter of OCI Artifacts:

The artifacts repository will serve 3 primary goals:

1. artifact authors - guidance for authoring new artifact types. Including a clearing house for well known artifact types.
2. registry operators and vendors - guidance for how operators and vendors can support new artifact types, including how they can opt-in or out of well known artifact types. Registry operators that already implement media-type filtering will not have to change. The artifact repo will provide context on how new media-types can be used, and how media-types can be associated with a type of artifact.
3. clearing house for well known artifacts - artifact authors can submit their artifact definitions, providing registry operators a list by which they can easily support.

The "clearing house for well-known types" evolved to Registering Unique Types with IANA, which alleviated OCI artifact maintainers from becoming the bottleneck.

The main value for OCI Artifacts became: Artifact Authors Guidance which helps authors and registry operators understand how to implement and support new artifact types. With the addition of the artifactType, subject property and /referrers api used across the specs, the info will need to be updated to reflect the new functionality.

Regarding the /artifacts repo being out of date, this was intentional as it was agreed to pause (artifacts PR #29) while the reference types made the circle from being implemented under the oras/artifact-spec, back to the OCI Working Group: Reference Types and now back to the Image and Distribution specs. The OCI Artifacts repo was a stability point while the formalization is being completed.

The guidance in OCI Artifacts is still accurate, as the guidance is both backwards and forward compatible. What's being added is formalization of the config.mediaType to artifactType and the additional reference type capabilities. I'm looking forward to the 1.1 release so the community and start to adopt the final version.

As incremental steps, before archiving the artifacts repo, I'd suggest:

1. Update the Image and Distribution specs charter to include guidance for authors and registry operators.
2. Once the image and artifacts repo finalize a 1.1 release, the artifacts repo can make updates to direct users to the new content.(see Artifacts pr #68) This would resolve the many links to OCI Artifact and its guidance spread across blogs and documentation.
3. Upon completion of the above steps, archive the repo.
   🎉

[jdolitsky]

@SteveLasker This sounds mainly good:

As incremental steps, before archiving the artifacts repo, I'd suggest:

1. Update the Image and Distribution specs charter to include guidance for authors and registry operators.
2. Once the image and artifacts repo finalize a 1.1 release, the artifacts repo can make updates to direct users to the new content.Update README.md artifacts#68 This would resolve the many links to OCI Artifact and its guidance spread across blogs and documentation.
3. Upon completion of the above steps, archive the repo.

Can we put together PRs to add an ARTIFACTS.md file in image-spec/distirbution-spec that captures all of this for number 1 on your list? We can keep the files in this repo to link back to, then just make the README similar to:

---

OCI Artifacts (archived)

This repo has been archived since July 2023.

The creation of this repository and subsequent efforts within OCI (i.e. Working Group: Reference Types (archived)) have resulted in the following pages which provide guidance for OCI Artifact Authors relating to implementing a single OCI specification:

• Supporting OCI Artifacts in image-spec (v1.1+)
• Supporting OCI Artifacts in distribution-spec (v1.1+)

---

??

[SteveLasker]

Once the 1.1 spec is released, there’s lots of good conversations.

[jdolitsky]

there's a good conversation right in front of you!

[SteveLasker]

Yup, and I'm looking forward to this making its completion. However, the churn that’s happened along the way has caused confusion, frustration, and randomization across cloud providers and implementers.
The artifacts repo has been a point of stability for how authors and registry operators can enable capabilities today, across all registries. And, a call for a Releases Please #23 demonstrated the need for a versioned, stable release.
I was more hopeful with the first RCs, but the late-breaking changes of Remove artifact manifest #999, after several cloud providers and projects implemented the RC, is the validated concern.
If the image and distribution spec had documentation that covered the charter of OCI Artifacts, specifically updated content of the Artifact Authors Guidance, that would be a great start to point people to.

[SteveLasker]

I'd also suggest the emojis don't exactly build trust around inclusive, positive collaboration.

[dlorenc]

This is basically the exact opposite of my interpretation of how the last few years have gone in the OCI.

Based on past experiences discussing things with you, I don't think we're going to have a productive discussion so I'm not going to continue but I felt it worthwhile to at least provide a counter interpretation on the history of OCI artifacts for future readers.