Proposal: working group for reference types #103
Conversation
Signed-off-by: Steve Lasker <[email protected]>
| * Microsoft | ||
| * AWS | ||
| * Docker | ||
|
|
There was a problem hiding this comment.
From #96, there's an open clarification if Google will be a sponsor.
There was a problem hiding this comment.
If there's an open question we should resolve that before voting.
There was a problem hiding this comment.
@jonjohnsonjr, can you clarify if Google will be a sponsor?
There was a problem hiding this comment.
Would it effect the vote either way? I'm no longer at Google, but if I remember the process correctly, getting an actual answer here will be very annoying and time consuming.
There was a problem hiding this comment.
I'd rather not start the voting process if we expect the thing we're voting on to change. If @SteveLasker wants to drop the question and we vote on the proposal as-is that would be fine to me.
There was a problem hiding this comment.
I'm happy to add cosign to the list if that helps. I'm also happy to leave it off if that helps get the vote started faster.
There was a problem hiding this comment.
If it's a point of contention, I suggest we just remove any notion of "corporations" as sponsors as the work done under this WG has been discussed at length without any specific need for guidance/sponsorship from the employers/entities themselves.
I understand initially the list was denoting companies which a specific interest in this work and had people involved for that purpose, but I think we've made it clear this is an open WG that will hopefully involve input from any registry operator, open source registry implementation, clients, etc.
Delaying at this point to formalize or determine a list of company names seems unnecessary given we have struggled for months to get this rolling and are all fully aware of the work that needs to be accomplished collaboratively no matter who is listed in this proposal. My intent was to hopefully involve a good cross-section of people, which should be much larger than just the "owners", but the owners list will help shepherd the discussion, status, and progress of the group and, in my opinion, is a good cross-section of people with OCI history, registry open source projects, operating registries, and so on.
There was a problem hiding this comment.
exactly what phil said. While I'm sure that "sponsor" equates to "my employer allows me to allocate time to this, and is interested in seeing this completed", it would be tedious to tease that out before getting this in.
I'd rather just see GH handles of the stakeholders that are going to see this through to completion.
There was a problem hiding this comment.
can't we just change this "Sponsor" to "Stakeholder" and move on with it?
There was a problem hiding this comment.
Changed sponsors to stakeholders.
With this change, are there any other changes before moving to the vote?
Signed-off-by: Steve Lasker <[email protected]>
| * Document user expectations for promoting an artifact between registries with its references | ||
| * Document onboarding process for registries and user-facing tools to adopt reference types | ||
| * Defined expectations for artifact reference lifecycle management | ||
| * Deliver a reference implementation of the reference types proposal |
There was a problem hiding this comment.
Just a note per the Governance section and the relevant parts of the Charter: a new reference implementation will require a new TOB vote at the time it is ready for it to become an OCI Project.
There was a problem hiding this comment.
I'd probably drop this or downgrade to a proof of concept. It's going to be confusing to talk about the reference reference implementation.
| * https://github.com/opencontainers/artifacts/pull/37 | ||
| * https://github.com/opencontainers/image-spec/issues/827 | ||
| * https://github.com/opencontainers/image-spec/pull/828 | ||
| * https://github.com/oras-project/artifacts-spec/ |
There was a problem hiding this comment.
Just a note here that this repository is not itself an OCI Project even though many of the people working on it are also involved in OCI (and in this proposed WG).
| ## Intended work product | ||
|
|
||
| * Referrers API specification that provides the ability to discover references to existing container images. These include listing signatures, SBoMs, security scan results that refer to the digest of a manifest. The referrers API specification will sit within or along side the Distribution specification. | ||
| * Identify, and document the pros and cons for versioning the existing manifests, compared with creating a new manifest to support reference types. |
There was a problem hiding this comment.
| * Identify, and document the pros and cons for versioning the existing manifests, compared with creating a new manifest to support reference types. | |
| * Proposal to extend existing manifests or create a new manifest to support reference types. |
There was a problem hiding this comment.
To address any of the existing manifests, we do need to address how these would be versioned. So, I propose we leave this as stated as the updated wording does change the process.
There was a problem hiding this comment.
Just documenting the pros and cons doesn't feel like a great work product. Having a concrete proposal for existing manifests feels like a prerequisite for doing this analysis, so if that's implied by what you have here, that's fine with me.
There was a problem hiding this comment.
Ahh, I see, so it's a merger of the two.
What I didn't want to lose was the versioning analysis, and just jump into debating solutions. I've merged both concepts.
| * Document impact to existing user-facing tools and registries | ||
| * Define the method for creating, distributing, and discovering referenced objects | ||
| * Document user expectations for promoting an artifact between registries with its references | ||
| * Document onboarding process for registries and user-facing tools to adopt reference types |
There was a problem hiding this comment.
| * Document onboarding process for registries and user-facing tools to adopt reference types | |
| * Document path to adoption for registries and other implementations |
Signed-off-by: Steve Lasker <[email protected]>
|
I've incorporated the typo/linting feedback. I left the subtle scope changing as we had previously agreed to this scope, and these steps were a call for a vote to move forward on the scope. Changing the scope would reset the LGTM and reviews. I'll also note, not being able to simply hit the [Commit suggestion] button, that supports DCO is still outstanding: todogroup/gh-issues#50 |
…anifest Signed-off-by: Steve Lasker <[email protected]>
|
Vote tally: 7/9 TOB members voted LGTM. The proposal passes.
|
|
The proposal passes, we will merge and begin onboarding for the WG |
Per discussion on the November 18, 2021 OCI weekly call, feedback from @dmcgowan was to convert the issue to a proposal. @vbatts, @estesp and others on the call agreed.
PR contents copied from Issue #96
The issue is open for voting by the OCI TOB members, through Midnight December 1, 2021.
Voting will be tallied at the December 2nd, 2021 OCI Weekly call.
Signed-off-by: Steve Lasker [email protected]