Comments (13)
I for one am on board for a rename of image spec and clarification of the different structures.
Since it was brought up recently about moving something like the descriptor from image-spec into distribution-spec, it was pointed out that this would be a breaking change.
This kind of breaking changes will be the focus
from wg-reference-types.
Seems like we are on the same page on this, closing
from wg-reference-types.
The OCI Artifacts repo was always intended to evolve to support broader scenarios. We said it was scoped, at the time, but I don't think it was ever said it couldn't evolve, rather it needs TOB approval to become a spec.
My personal opinion has always been the artifacts repo should converge into the distribution-spec, as the distribution-spec should have the manifest definitions for what it supports. This is simply the evolution that the distribution-spec supports all types of artifacts (container images, helm charts, signatures, sboms, bicep modules, etc.)
from wg-reference-types.
The OCI Artifacts repo was always intended to evolve to support broader scenarios. We said it was scoped, at the time, but I don't think it was ever said it couldn't evolve, rather it needs TOB approval to become a spec. My personal opinion has always been the artifacts repo should converge into the distribution-spec, as the distribution-spec should have the manifest definitions for what it supports. This is simply the evolution that the distribution-spec supports all types of artifacts (container images, helm charts, signatures, sboms, bicep modules, etc.)
I don't think the intention of the WG was to propose anything to the artifacts repo. Instead, I believe we intend to propose changes to the existing OCI specs (somebody please correct me if I'm wrong).
How and whether artifacts evolves toward becoming a spec, or part of a spec, feels separate and orthogonal to me in answering how (or whether) the reference types WG's proposals land in OCI specs.
from wg-reference-types.
The only reason I mention anything besides image-spec/distribution-spec is the new manifest type being proposed in Proposal E: https://github.com/opencontainers/wg-reference-types/blob/main/docs/proposals/PROPOSAL_E.md#artifact-spec
Where would that belong? In my opinion, this either
- Lands in image-spec alongside other documentation for supported manifest types
- Lands in a new artifact-spec repo that feels similar to image-spec
from wg-reference-types.
The only reason I mention anything besides image-spec/distribution-spec is the new manifest type being proposed in Proposal E: https://github.com/opencontainers/wg-reference-types/blob/main/docs/proposals/PROPOSAL_E.md#artifact-spec
Where would that belong? In my opinion, this either
- Lands in image-spec alongside other documentation for supported manifest types
- Lands in a new artifact-spec repo that feels similar to image-spec
or distribution spec, or rename/rescope artifacts, or some other combination...
is a good sign the wg is getting closer to a proposal/output :-)
from wg-reference-types.
The simplest option to me seems to be be to keep the new manifest types in image-spec, and perhaps consider renaming it later. It already includes other types such as descriptor and index, so another one isn't that far from where we are today.
Then the new API changes would live in distribution-spec.
from wg-reference-types.
Proposal: Decoupling Registries from Specific Artifact Specs #91
from wg-reference-types.
Ultimately, this will be a TOB decision. (Perhaps tagging @opencontainers/tob will raise some visibility).
I believe we will have changes to image-spec and distribution-spec that will document here and then raise as PR's to this projects.
For artifact-spec, we can define what that should look like as a folder within the WG repo. Once we get to that point, the TOB can make the decision on whether that gets pushed as a new repo, artifacts gets renamed and extended with new content, or artifacts gets merged into the new artifacts-spec repo.
The other option I thought about for artifact-spec was to create a new repo and have the WG populate it ourselves. That might get more complicated with sorting out maintainers of the new repo just to make the proposal, so I was leaning towards the simple solution of a directory in this repo.
The simplest option to me seems to be be to keep the new manifest types in image-spec, and perhaps consider renaming it later. It already includes other types such as descriptor and index, so another one isn't that far from where we are today.
I was pushing for that early on, but it got shot down. I believe the image-spec maintainers want to limit the scope of their repo.
from wg-reference-types.
I was pushing for that early on, but it got shot down. I believe the image-spec maintainers want to limit the scope of their repo.
Do you have a link to that? I don't remember it :(
Keeping all the manifest specs together seems the simplest to me. The maintainers have changed, so it might be worth revisiting.
from wg-reference-types.
I'm not sure when exactly that was, but I'm pretty sure it was within the last year. @samuelkarp may remember.
from wg-reference-types.
Thanks for the tag @sudo-bmitch!
I believe the image-spec maintainers want to limit the scope of their repo.
I don't really have a memory of this, but possibly opencontainers/image-spec#907 (@vbatts) is relevant here as it implies that the image-spec maintainers think things-that-are-not-images might not belong in the image-spec?
The simplest option to me seems to be be to keep the new manifest types in image-spec, and perhaps consider renaming it later. It already includes other types such as descriptor and index, so another one isn't that far from where we are today.
Then the new API changes would live in distribution-spec.
My initial inclination is to agree with this, but (a) I'm not speaking on behalf of the TOB here, (b) I haven't really been following the WGs efforts so I'm not up to date on the details of any proposal, and (c) I'd want to hear both what the WG itself wants to propose as well as what the image-spec maintainers think about it.
is a good sign the wg is getting closer to a proposal/output :-)
💯 I'm excited to see that we're getting closer!
from wg-reference-types.
I for one am on board for a rename of image spec and clarification of the different structures.
@vbatts we discussed on the call and agree we should go this general direction.
Maybe rename image-spec to github.com/opencontainers/schema
with subdirectories:
artifact-spec/
image-spec/
??
Either way, we seemed to agree on 2 PRs as the initial output of this working group:
- To image-spec: Modification of existing spec and adding new artifact-spec
- To distribution-spec: Addition of new referrers API endpoints
from wg-reference-types.
Related Issues (20)
- Proposal B: Mediatypes should always be OCI standard ones
- Disambiguate "reference" HOT 6
- Updates to Proposal E HOT 12
- Make artifactType a first-class field? HOT 1
- Issues with Proposal E HOT 7
- What are the issues with Proposal D? HOT 12
- Add Proposal F HOT 26
- What are the issues with Proposal F? HOT 12
- Picking a direction for the working group HOT 3
- Questions on "Cherry Pick" :cherries: HOT 5
- [Vote] Should artifact type move out of annotations HOT 10
- [Vote] Should we switch to predictable digest tags HOT 13
- Why not bump schemaVersion on existing manifest? HOT 8
- Is there a reason indexes don't get a refers list in prop e? HOT 6
- Prop E artifact annotations questions HOT 2
- [Vote] Partition digest tags by type HOT 6
- [Vote] Allow for server-side filtering using artifactType HOT 5
- Archive this repository? HOT 1
- Can we define the behaviour for a missing reference? HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wg-reference-types.