forked from opencontainers/runtime-spec
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'origin/master' into tk/restore-hook-lif…
…ecycle
After unifying the pre- and post-split hook lifecycle information
(this commit's first parent), merge master to pull in subsequent
mainline evolution.
Conflicts:
runtime.md
The conflicts were primarily due to:
* dd0cd21 (Add a 'status' field to our state struct, 2016-05-26, opencontainers#462).
* 98f0bdf (Add some related docs links, 2016-10-25, opencontainers#596).
* c45ffb4 (*: Replace "user-specified code" with "user-specified
program", 2016-11-18, opencontainers#629).
Signed-off-by: W. Trevor King <[email protected]>- Loading branch information
Showing
32 changed files
with
1,365 additions
and
479 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,3 @@ | ||
| output | ||
| schema/validate | ||
| code-of-conduct.md | ||
| version.md |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,17 +1,22 @@ | ||
| language: go | ||
| go: | ||
| - 1.6 | ||
| - 1.5.3 | ||
| - 1.7 | ||
| - 1.6.3 | ||
| - 1.5.4 | ||
|
|
||
| sudo: false | ||
| sudo: required | ||
|
|
||
| services: | ||
| - docker | ||
|
|
||
| before_install: | ||
| - make install.tools | ||
| - docker pull vbatts/pandoc | ||
|
|
||
| install: true | ||
|
|
||
| script: | ||
| - make .govet | ||
| - make .golint | ||
| - make .gitvalidation | ||
|
|
||
| - make docs |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,70 @@ | ||
| # Project governance | ||
|
|
||
| The [OCI charter][charter] §5.b.viii tasks an OCI Project's maintainers (listed in the repository's MAINTAINERS file and sometimes referred to as "the TDC", [§5.e][charter]) with: | ||
|
|
||
| > Creating, maintaining and enforcing governance guidelines for the TDC, approved by the maintainers, and which shall be posted visibly for the TDC. | ||
| This section describes generic rules and procedures for fulfilling that mandate. | ||
|
|
||
| ## Proposing a motion | ||
|
|
||
| A maintainer SHOULD propose a motion on the [email protected] mailing list (except [security issues](#security-issues)) with another maintainer as a co-sponsor. | ||
|
|
||
| ## Voting | ||
|
|
||
| Voting on a proposed motion SHOULD happen on the [email protected] mailing list (except [security issues](#security-issues)) with maintainers posting LGTM or REJECT. | ||
| Maintainers MAY also explicitly not vote by posting ABSTAIN (which is useful to revert a previous vote). | ||
| Maintainers MAY post multiple times (e.g. as they revise their position based on feeback), but only their final post counts in the tally. | ||
| A proposed motion is adopted if two-thirds of votes cast, a quorum having voted, are in favor of the release. | ||
|
|
||
| Voting SHOULD remain open for a week to collect feedback from the wider community and allow the maintainers to digest the proposed motion. | ||
| Under exceptional conditions (e.g. non-major security fix releases) proposals which reach quorum with unanimous support MAY be adopted earlier. | ||
|
|
||
| A maintainer MAY choose to reply with REJECT. | ||
| A maintainer posting a REJECT MUST include a list of concerns or links to written documentation for those concerns (e.g. GitHub issues or mailing-list threads). | ||
| The maintainers SHOULD try to resolve the concerns and wait for the rejecting maintainer to change their opinion to LGTM. | ||
| However, a motion MAY be adopted with REJECTs, as outlined in the previous paragraphs. | ||
|
|
||
| ## Quorum | ||
|
|
||
| A quorum is established when at least two-thirds of maintainers have voted. | ||
|
|
||
| For projects that are not specifications, a [motion to release](#release-approval) MAY be adopted if the tally is at least three LGTMs and no REJECTs, even if three votes does not meet the usual two-thirds quorum. | ||
|
|
||
| ## Security issues | ||
|
|
||
| Motions with sensitive security implications MUST be proposed on the [email protected] mailing list instead of [email protected], but should otherwise follow the standard [proposal](#proposing-a-motion) process. | ||
| The [email protected] mailing list includes all members of the TOB. | ||
| The TOB will contact the project maintainers and provide a channel for discussing and voting on the motion, but voting will otherwise follow the standard [voting](#voting) and [quorum](#quorum) rules. | ||
| The TOB and project maintainers will work together to notify affected parties before making an adopted motion public. | ||
|
|
||
| ## Amendments | ||
|
|
||
| The [project governance](#project-governance) rules and procedures MAY be amended or replaced using the procedures themselves. | ||
| The MAINTAINERS of this project governance document is the total set of MAINTAINERS from all Open Containers projects (runC, runtime-spec, and image-spec). | ||
|
|
||
| ## Subject templates | ||
|
|
||
| Maintainers are busy and get lots of email. | ||
| To make project proposals recognizable, proposed motions SHOULD use the following subject templates. | ||
|
|
||
| ### Proposing a motion | ||
|
|
||
| > [{project} VOTE]: {motion description} (closes {end of voting window}) | ||
| For example: | ||
|
|
||
| > [runtime-spec VOTE]: Tag 0647920 as 1.0.0-rc (closes 2016-06-03 20:00 UTC) | ||
| ### Tallying results | ||
|
|
||
| After voting closes, a maintainer SHOULD post a tally to the motion thread with a subject template like: | ||
|
|
||
| > [{project} {status}]: {motion description} (+{LGTMs} -{REJECTs} #{ABSTAINs}) | ||
| Where `{status}` is either `adopted` or `rejected`. | ||
| For example: | ||
|
|
||
| > [runtime-spec adopted]: Tag 0647920 as 1.0.0-rc (+6 -0 #3) | ||
| [charter]: https://www.opencontainers.org/about/governance |
Oops, something went wrong.