opencontainers / tob Goto Github PK
View Code? Open in Web Editor NEWTechnical Oversight Board (TOB)
Home Page: https://groups.google.com/a/opencontainers.org/forum/#!forum/tob
License: Apache License 2.0
Technical Oversight Board (TOB)
Home Page: https://groups.google.com/a/opencontainers.org/forum/#!forum/tob
License: Apache License 2.0
Now that the OCI TOB is established for 2018, we need to elect a new chair.
@amye and I will work in tandem with the @opencontainers/tob to audit the current list of maintainers.
We will make recommendations based on the data we present to the TOB :)
Hey @opencontainers/tob, I will be opening the call for nominations for the OCI TOB Chair position detailed above. Last year, we only had one volunteer via @crosbymichael
One of the TOB's pain points in governance is the lack guidance on how to deal with not enough maintainers reviewing changes to individual OCI Projects.
The current charter says the following on oversight of TDCs:
The TOB shall not dictate or interfere with the day-to-day work of individual OCI Projects or their decisions.
This means that the TOB cannot effectively resolve issues in the TDC that stem from inactive maintainers. What is the TOB's role in this regard?
I've been thinking a bit about umoci and ORAS proposals (#67 and #68) - how do people feel about some generic new repo like opencontainers/tools
which could contain a collection of various tools enabling OCI-related work?
Some initial tools we can include:
This repo can have its own criteria for which tools should be added vs. going through the TOB. This reduces the burden on TOB for "blessing" certain tools, while these tools still benefit from being under the opencontainers
namespace.
We could organize it using top-level directories in the repo corresponding to the tool, for example:
|____tools/
| |____oras
| | |____README.md
| | |____<oras_source>
| |____reggie
| | |____README.md
| | |____<reggie_source>
| |____umoci
| | |____README.md
| | |____<umoci_source>
This introduces some challenges around the release process and how maintainers operate, but perhaps it's the best approach all things considered. I'm imagining the repo adopting several other tools people would be willing to contribute. It may also serve as a new home for other repos like go-digest
, runtime-tools
, and image-tools
.
Thoughts? Happy to help organize and maintain a repo like this.
A new year means a new election:
Each OCI member can submit up to one candidate for nomination, which they are then voted upon by OCI membership. Here are the relevant sections from the OCI charter:
https://www.opencontainers.org/about/governance
e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.
f. TOB members shall be split into two (2) groups, serving for a term of two (2) years on a staggered basis, where one group is elected each year. The initial TOB will have four (4) TOB members who will only serve for a term of one year and five (5) TOB members that serve for a term of two (2) years.
g. The initial TOB shall be established through a nomination and election process. The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year. Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company. The second group from which five (5) TOB members shall be elected, will be nominated and elected by the OCI Members and serve for a period of two (2) years. Each OCI Member may nominate one (1) candidate for election.
We currently do not have a process for OCI Project removal and archival. It's unclear whether these should even be considered two separate processes. The TOB does have the right to remove projects under Section 2 (b) of the Charter, but it seems like this is something which should be slightly more formalised (such as requiring a 30 day notice with a comment period before archival of the project -- and likely we would never want to outright remove a project from the OCI).
Are there any strong opinions about what the process should be? In keeping with the apparent consensus on the TOB calls, we should probably make this as minimal as possible.
I am writing this as a separate issue, because it won't be included in my first round of charter refactoring but it is something that I wanted to open a discussion about.
Red Has announced an agreement to acquire CoreOS:
https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership
The @opencontainers/tob has certain rules in place to ensure only a certain number of representatives can be from one entity:
e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.
I will reach out to Red Hat to see which two candidates they desire to keep on the TOB. After that is done, I will run another election for the newly available TOB slot.
My proposed timeline:
Adopt the ORAS project located at deislabs/oras.
ORAS is a CLI that can publish arbitrary content to an OCI registry, with special features for setting mediatypes on manifest configs and on content.
Note: the manifest mediatype itself is always application/vnd.oci.image.manifest.v1+json
.
Example - uploading rockets, a brand new type of package:
# Create a thing
printf '🚀' > rocket.txt
# Create a manifest config
printf '{"RocketVersion":"v0.1.0"}' > rocket-config.json
# Upload your thing with a custom mediatype
oras push localhost:5000/mystuff/myrocket:v0.1.0 rocket.txt:text/plain \
--manifest-config rocket-config.json:application/vnd.acme.rocket.config.v1+json
See manifest created:
$ curl -s -H 'Accept: application/vnd.oci.image.manifest.v1+json' \
http://localhost:5000/v2/mystuff/myrocket/manifests/v0.1.0 | jq
{
"schemaVersion": 2,
"config": {
"mediaType": "application/vnd.acme.rocket.config.v1+json",
"digest": "sha256:310175f34d2d4d5cba3418be06ddd1ef948147d729516d78318ec7f5c2d83d49",
"size": 26
},
"layers": [
{
"mediaType": "text/plain",
"digest": "sha256:ebbc0b2870eb323f2b6cffa5c493ceef81ae7eb36afc73d4e0367301631daec5",
"size": 4,
"annotations": {
"org.opencontainers.image.title": "rocket.txt"
}
}
]
}
Get that thing:
$ curl -s http://localhost:5000/v2/mystuff/myrocket/blobs/sha256:ebbc0b2870eb323f2b6cffa5c493ceef81ae7eb36afc73d4e0367301631daec5
🚀
ORAS is built primarily on top of Go packages provided by containerd, but it also imports packages from the docker/cli, which enables "docker-style" auth login:
oras login -u username -p password localhost:5000 -c rocket-creds.json
There are also public Go packages available to build on top of ORAS. The following is the equivalent of the rocket example with the CLI above, but in Go:
package main
import (
"context"
"fmt"
"github.com/containerd/containerd/remotes/docker"
"github.com/deislabs/oras/pkg/content"
"github.com/deislabs/oras/pkg/oras"
ocispec "github.com/opencontainers/image-spec/specs-go/v1"
)
func main() {
ctx := context.Background()
resolver := docker.NewResolver(docker.ResolverOptions{})
store := content.NewMemoryStore()
registryRootURL := "localhost:5000"
registryNamespace := "mystuff/myrocket"
rocketVersion := "v0.1.0"
rocketFileName := "rocket.txt"
rocketMediaType := "text/plain"
rocketContent := []byte("🚀")
rocketDescriptor := store.Add(rocketFileName, rocketMediaType, rocketContent)
rocketConfigMediaType := "application/vnd.acme.rocket.config.v1+json"
rocketConfigContent := []byte(fmt.Sprintf("{\"RocketVersion\":\"%s\"}", rocketVersion))
rocketConfigDescriptor := store.Add("", rocketConfigMediaType, rocketConfigContent)
ref := fmt.Sprintf("%s/%s:%s", registryRootURL, registryNamespace, rocketVersion)
_, err := oras.Push(ctx, resolver, ref, store, []ocispec.Descriptor{rocketDescriptor},
oras.WithConfig(rocketConfigDescriptor))
if err != nil {
panic(err)
}
fmt.Println("Pushed to", ref)
fmt.Printf("\nTry:\n\ncurl -s -H 'Accept: application/vnd.oci.image.manifest.v1+json' \\\n" +
" %s/v2/%s/manifests/%s | jq\n", registryRootURL, registryNamespace, rocketVersion)
}
You can see all features in the project README.
The following projects are already successfully using ORAS to work with custom artifacts:
For a few reasons:
A start was made on thinking about how various repos within the OCI currently fit into a set of project types (specs, reference implementations, helper libraries). We need to finish this effort and publish it to provide guidance to both the TOB (for voting on new proposals) as well as future potential submissions to make is less vague on what fits in the OCI scope.
A start on this effort is located in the TOB call notes: https://hackmd.io/kKl1ECKnSLWhgk7dZ2WUFQ#Categorizing-Project-Types
opencontainers/image-spec#486 introduces a dependency on a stable upstream implementation of https://github.com/docker/go-digest, which was recently broken out of the https://github.com/docker/distribution project.
This package has been instrumental in providing a strong hash-identity implementation in Go and I hope to extend this to OCI.
Let's support this by moving this into a https://github.com/opencontainers/go-digest project specifically oriented towards providing this functionality throughout the container ecosystem. While this package does support opencontainers/image-spec, it is broadly useful in other image formats or outside image formats.
Having a solid, battle-proven, common digest implementation in OCI for use in and outside the image-spec will ensure long lasting security and interoperability throughout the container ecosystem.
Provisions:
All of the references to "Executive Director" in the Charter are written as "Linux Foundation Executive Director" or "Executive Director of the Linux Foundation" (who is Jim Zemlin). @caniszczyk is the Executive Director of the OCI, but it seems like the Charter seems to imply that he has no procedural powers because there are no references to his position? In fact as far as I can tell, it doesn't even establish his existence.
Is this a mistake -- should all of the references to "Executive Director of the Linux Foundation" or "Linux Foundation Executive Director" actually be "OCI Executive Director"?
This is the tracking issue for the onboarding administrative tasks for the Reference types working group:
Related issues/PRs
cc @justincormack @dmcgowan @jonjohnsonjr @michaelb990
At the OCI F2F (https://docs.google.com/document/d/1rL4wiY6Q7R199wz0PBtbbPVjMo_3v2BpO6c1kItPTLw/edit), we discussed kicking off a distribution specification project, based on the Docker distribution spec: https://twitter.com/chanezon/status/938845534466596864
We will have to go through the official OCI channels, which involves a project proposal to the @opencontainers/tob.
We have a few issues we're all wrestling with, with varied approaches and opinions on how to solve a problem. I'd suggest we each have slightly different priorities and we're focusing on the problems we either think we need or can solve. Unfortunately, we have come to a point where we have some bottlenecks in what extensibility we have.
To help frame a discussion, I'd suggest we need a framework for the discussions:
We have at least 2 major categories of changes:
What are the constraints we're trying to adhere to:
"Not break" means we can add behaviors, but do it in a deterministic way.
To confront, head-on, some concerns we're all facing:
I don't believe anyone desires the image-spec to be frozen. Rather, the question is: How do we make changes to the image-spec without breaking down-stream clients?
The varied designs around OCI Artifacts, Notary v2, cosign/sigstore, Compression Support all bump into this question, which we haven't actually clarified.
Facts:
image-spec
and image-index
to manage content.artifactType
The question could then be sub-categorized as:
Are we in agreement to the following?
There are three proposals up for consideration, with pros and cons associated with each. Before we can get into the pros & cons, there's presumptions for how OCI will support extensibility.
There's been confusion on how to directly update the scope table:
https://www.opencontainers.org/governance/oci-scope-table
Lets come up with a proposal to clarify the last section:
MECHANISM FOR ADDING “ROWS” TO THIS TABLE
The appropriate mechanism for adding, removing or modifying rows to this table (e.g. creating a proposal for an additional optional layer) is to bring it before the TDC. The TOB can be a source of appeal and/or can discuss if there isn’t a clear consensus in the TDC.
We need to elect an OCI TOB Chair starting next week
The seat is currently held by @estesp :)
We will have nominations open until Feb 3rd EOD PT time for the TOB
Per many discussions, and most recently in the @opencontainers/tob call, the scope table is clearly out of date and not applicable to the current state of the OCI.
Options are drop it with the governance update work in #72, or rewrite it/replace it with a prose version that flows from a clear expression of why the OCI exists followed by a list of projects and their reasons for existing in the OCI universe of projects. Feedback is that there is no clear, understandable place to understand these core ideas and to differentiate newcomer's understanding of OCI vs. CNCF, as one example.
Related: #10 (would potentially be superseded by a rewrite as a non-table and would not require any special rules to update)
@SteveLasker has suggested it would be great to have standardized icons for container related things, OCI is happy to fund this work, here are some things suggested to iconify:
We should be wary about any overlap with the kubernetes stencil set: https://github.com/kubernetes/community/tree/master/icons
A new year means a new election:
FYI: @opencontainers/tob
Much of the current release process draft focuses on maintainers, it may be worthwhile to add some specificity on how non-maintainers provide feedback.
/cc @philips
Proposal created from OCI WG template.
This document describes the basic governance principles for the Reference Types Working Group (the “WG”).
The WG operates as an OCI Working Group under the Open Container Initiative (OCI) Charter, which describes the responsibilities of the OCI Technical Oversight Board (the "TOB”). The WG is established by the TOB as an OCI Working Group pursuant to the OCI Charter. Accordingly, the WG will operate in accordance with the OCI Charter and OCI's other policies and procedures, supplemented by the details below.
As cloud native development continues to grow, there is increased interest in evolving registries to natively store, discover, and pull a graph of content associated with specific container images in a registry. Use cases for said associated artifacts include but are not limited to Software Bill of Materials (SBoM), security scan results, and signing. Having a native way to store and discover artifacts associated with other artifacts enables end-users to answer the question of: “What SBOMs or signatures are associated with this container image?”
This is listed under "Tier 1: Replace Immediately" in the Inclusive Naming Initiative:
https://inclusivenaming.org/word-lists/tier-1/#master
FYI @opencontainers/tob, just a friendly reminder that some 4 spots will open up in the TOB early next year:
@crosbymichael, @gregkh, @xemul and @vbatts spots will open up. They are free to nominate themselves and run again though if they so wish. A simple reminder that nominations will come from the TDC maintainers (everyone in a MAINTAINERS file).
"The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year"
"Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer."
We will also elect a new TOB chair directly afterwards and by Feb 11th.
My proposed schedule is this:
Let me know if you have any comments.
Okay, so the OCI Charter currently states that votes must pass with a super-majority (two-thirds). However, it seems that some sections conflict on the question of exactly how two-thirds are counted and I'd like to clarify whether these different voting rules are intentional:
Section 6 (n) states that all votes are passed with two-thirds of votes cast (this sentence is also phrased very strangely, mentioning the Trademark Board in the middle -- in fact I believe this is a copy-paste error from Section 4 (d) which uses very similar wording.) I also hasten to mention that it looks like voting on GitHub isn't actually okay according to the Charter but 🤷.
The intention is for the TOB to operate by consensus. However, if consensus cannot be achieved, the Trademark Board shall vote on a decision. All TOB Votes, either at TOB meetings, via email or electronic voting service, shall pass with a two-thirds vote of votes cast, on a one (1) vote per TOB member basis. An abstain vote equals not voting at all. [emphasis added]
However, Section 2 (c) appears to say that project approvals require a two-third vote of the entire TOB (so not voting counts as a vote against the motion). Maybe it's okay that this is a different rule, but this is one of the most important roles of the TOB and it's a bit odd that in a later section the rule appears to be contradicted by an unqualified "all".
Any Member can bring forward a new project proposal to the TOB for review. Approval of new OCI Projects requires a two-thirds vote of the TOB. [emphasis added]
And then Section 6 (h) also appears to say that changing the system of voting requires a two-third vote of the entire TOB (so not voting counts as a vote against the motion):
Initial elections of TOB members shall be run using the Condorcet-IRV method through the Cornell online service (http://civs.cs.cornell.edu/). The TOB may change the methodology or service used in future elections via a two-thirds approval vote of the then-serving TOB. [emphasis added]
And again in Section 6 (j)(ii) for calling meetings:
[The TOB shall meet on an as-needed basis, in a timely manner after issues are directed to the TOB from:] as the TOB determines via vote of at least two-thirds of the TOB members [empahsis added]
And yet again in Section 12 (a) for amending the Charter:
This Charter may be amended by a two thirds vote of the Technical Oversight Board, subject to veto by The Linux Foundation Board of Directors for reasonable cause, with thirty (30) days’ notice to the OCI Members before taking effect. [emphasis added]
So it seems like Section 6 (n) is simply an incorrect copy-paste of the Trademark Board's rules (there are literally no more references to TOB votes in the Charter other than the exceptions to Section 6 (n) I've listed). And from memory, we've always run votes as though Section 6 (n) didn't exist. So should we just remove it (as part of the cleanup I'm working on)?
This question is quite important when it comes to non-meeting votes (where we do not technically have to establish a quorum) because in such cases a two-thirds vote could be less than two-thirds of TOB members -- which seems like a bad idea.
Now that the TOB Elections for 2017 are over, it's time to elect a new TOB chair:
#20
On Monday, October 12, 2020, representatives from Azure, AWS, Google, IBM, Docker, and GitHub met to discuss how, as an industry, we believe we can address the problem. We need a short term solution for the pending November 1st changes that enable stability through the holiday lockdowns, with a longer-term plan that helps customers adapt their workflows.
To avoid customer confusion, and finger-pointing, the cloud vendors and docker have agreed to co-author a paper providing guidance to customers for how they can adapt their workflows in incremental steps. The goal is to provide stability to an ecosystem, with an opportunity to innovate in a common direction. The Open Container Initiative (OCI) was intended to provide a vendor-neutral body of governance. We would like to publish the paper under the OCI umbrella in the coming weeks.
The content will be something like:
The draft doc is located here: Consuming Public Content
We hope to complete the paper by 11/23, giving time for review and posting prior to Nov 1s.
Each cloud vendor can then point their cloud specific docs on how to implement a buggered workflow, enabling local reliability and performance, without the risks of accessing public content in critical workflows.
The paper will also direct customers to use Docker Authentication for pulls from Docker Hub, providing identity within multi-tenant cloud services.
The @opencontainers/tob needs to elect a new chair for 2023!
Is anyone from the @opencontainers/tob interested in running?
@samuelkarp would you like to stand again?
We should list previous OCI TOB folks and thank them for their service!
Even if we have people willing to take on the role of maintainership, PRs to add these people are not even being reviewed. For example:
I propose that a supermajority 2/3 vote from TOB members can add or remove a maintainer from any subproject in order to keep OCI alive and well.
There are currently 3 avenues for engaging with the TOB: mailing list ([email protected] I believe), GitHub issues, and meetings.
Is there a preference? My vote is for GitHub issues first, mailing list second, and meetings third.
There's been a discussion in the OCI TDC about potentially moving the selinux library out of runc and into a new project (say something like opencontainers/libselinux)
I'm creating this issue as a placeholder while the OCI TDC finishes debating whether to move forward or not. If we move forward, we will consult the TOB and begin a formal project proposal.
cc: @mrunalp
We need to elect an OCI TOB Chair.
The seat is currently hold by @crosbymichael.
A new year means a new election:
FYI: @opencontainers/tob
Right now, it is forbidden for more than two TOB members to be employed by the same employer:
e. The TOB shall be composed of nine (9) individuals elected for their
expertise, contribution to the advancement of container technologies and are
considered to be thought leaders in the OCI ecosystem. Anyone may be elected
to the TOB, regardless of whether the individual is an employee of an OCI
Member, so long as they are an OCI TDC participant. A TOB member is elected
as an individual and not as a representative of his or her employer. No more
than two (2) TOB members may be employed by the same entity or its
affiliates. Affiliates shall be defined as entities owning 50% or more of an
entity, or owned by or under common ownership with each other. TOB members
may not designate alternative representatives.
However, there is no procedure for dealing with this rule being violated. There are two circumstances where this rule could be violated:
Due to a TOB election, there are more than two TOB members who are employed by the same entity (this could be that one TOB member was already an employee of FooBarCo, and two canidates were employees of FooBarCo, and both employees got above the necessary threshold of votes).
A TOB member changes employers (either willingly, or due to their employer being bought by another company) which employs two TOB members already.
In my view, these two circumstances should have separate procedures:
(1) should be handled by walking through the ranked list of candidates after the election has been completed, and adding each candidate if they are eligible. If they are not eligible, the next candidate in the ranked list is considered. If there is a tie (even after removing inelligible candidates from that tie), then a fair coin toss could be used.
(2) should be handled by a by-election for a subset of the TOB's seats. It might make the most sense to only have a by-election for the TOB members' whose employer has changed, but another option would be simply to have a by-election for all TOB seats which violate s6(e) to avoid discriminating against TOB members who . In either case, whoever is elected in the seats acts as an interim TOB member, and their term ends at the same time as the previous holder (in other words, the by-election doesn't give the new TOB member a two-year term). This procedure probably should be considered along with #82 to avoid any extra complications.
A new year means a new election:
Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company, which they are then voted upon by existing TDC maintainers. Here are the relevant sections from the OCI charter:
https://www.opencontainers.org/about/governance
e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.
f. TOB members shall be split into two (2) groups, serving for a term of two (2) years on a staggered basis, where one group is elected each year. The initial TOB will have four (4) TOB members who will only serve for a term of one year and five (5) TOB members that serve for a term of two (2) years.
g. The initial TOB shall be established through a nomination and election process. The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year. Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company. The second group from which five (5) TOB members shall be elected, will be nominated and elected by the OCI Members and serve for a period of two (2) years. Each OCI Member may nominate one (1) candidate for election.
A new year means a new election:
Call for Nominations will open on Mon, Nov 29 2021 and end on Mon, Jan 10 2022
Call for Votes will open Tue, Jan 11 2022 and end on Tue, January 18 2022.
Vote winner will be announced on Monday, January 24th
Each OCI member can submit up to one candidate for nomination, which they are then voted upon by OCI membership. Here are the relevant sections from the OCI charter:
https://www.opencontainers.org/about/governance
e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.
f. TOB members shall be split into two (2) groups, serving for a term of two (2) years on a staggered basis, where one group is elected each year. The initial TOB will have four (4) TOB members who will only serve for a term of one year and five (5) TOB members that serve for a term of two (2) years.
g. The initial TOB shall be established through a nomination and election process. The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year. Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company. The second group from which five (5) TOB members shall be elected, will be nominated and elected by the OCI Members and serve for a period of two (2) years. Each OCI Member may nominate one (1) candidate for election.
The 5 TOB slots open are:
From the charter's §6.e:
Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant.
And from §5.b:
b. The OCI TDC has an established scope of work focused on:
…
viii. Creating, maintaining and enforcing governance guidelines for the TDC, approved by the maintainers, and which shall be posted visibly for the TDC. The guidelines shall cover the following:
- establishing and defining roles and responsibilities (at a minimum, a role for committers or maintainers authorized to commit code to the codebase);
- defining the process or requirements to take on a role in the TDC (e.g. how to become a contributor, or how to become a maintainer);
- the process by which participants in the TDC may give up or be revoked of their roles (e.g. how to remove maintainers); the rules for decision making in the TDC; and the process by which participants in the TDC may give up or be revoked of their roles (e.g. how to remove maintainers); the rules for decision making in the TDC; and
As far as I'm aware, the only TDC role that any OCI Project has defined is “maintainer”. So I think non-maintainers are not TDC participants, and are therefore excluded from standing for TOB election.
However, the charter is not clear on a number of points. Perhaps my reading is missing the spirit of the charter and the charter-writers only intended that sentence to lift a potential OCI Member employee restriction. The charter is clear that the current TDC maintainers will be doing the electing of this round, and since those are the same folks who have the power to induct new TDC maintainers/participants, I don't see how restricting the candidates to current TDC participants serves any purpose. And for the OCI Member round of TOB elections, I don't see why OCI Members would want their candidate pool limited to current TDC participants, since they have no direct control over who that set of people is.
Proposal is to create a separate repository to cover Artifact Distribution.
Accounts for: Artifact registry support #65
The new repository would explain:
With artifacts defined here, the distribution spec can be updated to remove references to images, making it more about storing index and manifest references to layers.
Proposed repository name:
artifact-spec
N1-0 (@android:color/system_neutral1_android#
The OCI Release Process should differentiate between major and minor releases.
Possibly longer waiting period and higher threshold for consensus for major (vs. minor)
/cc @philips
Right now if the TDC Maintainers feel that the TOB is not fulfilling their duty correctly, they have no recourse other than to go to the Linux Foundation (and I'm not sure how that process would even work). Should we have a "no confidence motion" concept in the Charter (such as a qualified super-majority of TDC Maintainers can trigger the TOB be dissolved and a special election for all seats)? Then again, we've never had any tensions between the TOB and TDC Maintainers so maybe this is purely a theoretical thing which isn't worth extra text in the Charter? But then again, if we ever need it then it'd be too late to ask the TOB to add it.
I am writing this as a separate issue, because it won't be included in my first round of charter refactoring but it is something that I wanted to open a discussion about.
This issue was brought up at an OCI Certification Working Group.
Should it just share the runtime-spec MAINTAINERS or do we select a new set?
We don't need to address this immediately, but it's something we should get clarity on it in the future.
After speaking with @philips, we will do a proposed update of the OCI Code of Conduct to be more modern with the state of the art in this field. The LF best practice moving forward is having the community be the focal point of the enforcement (usually via a committee of some type). We can decide to just delegate this to the TOB, a subset of the TOB or a newly formed code of conduct committee.
Note, this will be a post v1.0 activity
A new year means a new election:
Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company, which they are then voted upon by existing TDC maintainers. Here are the relevant sections from the OCI charter:
https://www.opencontainers.org/about/governance
e. The TOB shall be composed of nine (9) individuals elected for their expertise, contribution to the advancement of container technologies and are considered to be thought leaders in the OCI ecosystem. Anyone may be elected to the TOB, regardless of whether the individual is an employee of an OCI Member, so long as they are an OCI TDC participant. A TOB member is elected as an individual and not as a representative of his or her employer. No more than two (2) TOB members may be employed by the same entity or its affiliates. Affiliates shall be defined as entities owning 50% or more of an entity, or owned by or under common ownership with each other. TOB members may not designate alternative representatives.
f. TOB members shall be split into two (2) groups, serving for a term of two (2) years on a staggered basis, where one group is elected each year. The initial TOB will have four (4) TOB members who will only serve for a term of one year and five (5) TOB members that serve for a term of two (2) years.
g. The initial TOB shall be established through a nomination and election process. The first group from which four (4) TOB members shall be elected, will be nominated and elected by the current TDC maintainers, initially identified in Section 4(e), and serve for a period of one (1) year. Each TDC maintainer may nominate up to two (2) candidates for election, except that only one (1) nominee may be employed by the TDC maintainer’s own company. The second group from which five (5) TOB members shall be elected, will be nominated and elected by the OCI Members and serve for a period of two (2) years. Each OCI Member may nominate one (1) candidate for election.
Per discussion with the @opencontainers/tob members in March/April 2020, there are aspects to the OCI governance which are significantly out of date or simply related to the early construct under which the OCI was formed in 2016.
After the move of opencontainers.org to GitHub (see the work underway in https://github.com/opencontainers/opencontainers.org) we should be able to do this with a standard GitHub pull request/approve/merge workflow.
Part of this work needs to specifically deal with the question of TDC vs. TOB vs. maintainers of OCI projects:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.