You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge branch 'master' of git://github.com/opencontainers/project-template into merge-project-template
To fulfill the TOB's [1]:
Both of the proposed projects would incorporate the Governance and
Releases processes from the OCI project template:
https://github.com/opencontainers/project-template.
which was approved with this vote [2].
Generated with:
$ git pull git://github.com/opencontainers/project-template.git master
$ git checkout --ours .pullapprove.yml README.md
$ git checkout --theirs CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md
$ git add .pullapprove.yml CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md README.md
$ git commit
I think there are a few improvements we could make to these template
docs [3,4,5], but the TOB vote happened before I'd floated those.
If/when they land, we can pull the updated versions into this
repository via a follow-up merge.
* 'master' of git://github.com/opencontainers/project-template: (33 commits)
.pullapprove.yml: Reset on push, ignore authors, and require sign-offs
GOVERNANCE.md: fix typo
GOVERNANCE and RELEASES: split the files
project-governance: Make voting more generic
proposals: release approval process explain security@ email
proposal: fix a typo
proposals: release-approval-process fix a grammar thing
release-approval: Add non-spec unanimous quorum reduction
release-approval: Shuffle to make more DRY
proposals: release-approval-process: fixup additional typos
proposals: release approval process: improve REJECT feedback
proposals: release approval process: add information to projects
proposals: release approval process: add language about mailing list
proposals: release approval process: add quorum language
proposals: release-approval-process: add voting members language
proposals: release approval process: clarify utility of GitHub
proposals: release approval process: use consistent language for rejects
proposals: release approval process: one month pre-releases
proposals: release approval process 3 rcs required
proposals: release approval process to one week for apps
...
Conflicts:
.pullapprove.yml
CONTRIBUTING.md
LICENSE
MAINTAINERS_GUIDE.md
README.md
[1]: https://github.com/opencontainers/tob/blob/8997b1aa221b3b61d4305bede41c257b879bdeeb/proposals/tools.md#governance-and-releases
[2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/rZ4luMa-pxY
Subject: VOTE Required: approve new projects: image-tools, runtime-tools
Date: Wed, 07 Sep 2016 22:37:32 +0000
Message-ID: <CAD2oYtMLMFQouEVU7HTO-EKnW6vKu82dGT+0mziXZzCyqngj=A@mail.gmail.com>
[3]: opencontainers/project-template#18
Subject: GOVERNANCE: Proposing a motion is a LGTM by default
[4]: opencontainers/project-template#19
Subject: GOVERNANCE: Drop the co-sponsor requirement
[5]: opencontainers/project-template#20
Subject: MAINTAINERS_GUIDE|CONTRIBUTING: Make generic enough for all OCI Projects
Signed-off-by: W. Trevor King <[email protected]>
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:
4
+
5
+
> Creating, maintaining and enforcing governance guidelines for the TDC, approved by the maintainers, and which shall be posted visibly for the TDC.
6
+
7
+
This section describes generic rules and procedures for fulfilling that mandate.
8
+
9
+
## Proposing a motion
10
+
11
+
A maintainer SHOULD propose a motion on the [email protected] mailing list (except [security issues](#security-issues)) with another maintainer as a co-sponsor.
12
+
13
+
## Voting
14
+
15
+
Voting on a proposed motion SHOULD happen on the [email protected] mailing list (except [security issues](#security-issues)) with maintainers posting LGTM or REJECT.
16
+
Maintainers MAY also explicitly not vote by posting ABSTAIN (which is useful to revert a previous vote).
17
+
Maintainers MAY post multiple times (e.g. as they revise their position based on feeback), but only their final post counts in the tally.
18
+
A proposed motion is adopted if two-thirds of votes cast, a quorum having voted, are in favor of the release.
19
+
20
+
Voting SHOULD remain open for a week to collect feedback from the wider community and allow the maintainers to digest the proposed motion.
21
+
Under exceptional conditions (e.g. non-major security fix releases) proposals which reach quorum with unanimous support MAY be adopted earlier.
22
+
23
+
A maintainer MAY choose to reply with REJECT.
24
+
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).
25
+
The maintainers SHOULD try to resolve the concerns and wait for the rejecting maintainer to change their opinion to LGTM.
26
+
However, a motion MAY be adopted with REJECTs, as outlined in the previous paragraphs.
27
+
28
+
## Quorum
29
+
30
+
A quorum is established when at least two-thirds of maintainers have voted.
31
+
32
+
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.
33
+
34
+
## Security issues
35
+
36
+
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 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.
39
+
The TOB and project maintainers will work together to notify affected parties before making an adopted motion public.
40
+
41
+
## Amendments
42
+
43
+
The [project governance](#project-governance) rules and procedures MAY be amended or replaced using the procedures themselves.
44
+
The MAINTAINERS of this project governance document is the total set of MAINTAINERS from all Open Containers projects (runC, runtime-spec, and image-spec).
45
+
46
+
## Subject templates
47
+
48
+
Maintainers are busy and get lots of email.
49
+
To make project proposals recognizable, proposed motions SHOULD use the following subject templates.
50
+
51
+
### Proposing a motion
52
+
53
+
> [{project} VOTE]: {motion description} (closes {end of voting window})
54
+
55
+
For example:
56
+
57
+
> [runtime-spec VOTE]: Tag 0647920 as 1.0.0-rc (closes 2016-06-03 20:00 UTC)
58
+
59
+
### Tallying results
60
+
61
+
After voting closes, a maintainer SHOULD post a tally to the motion thread with a subject template like:
The release process hopes to encourage early, consistent consensus-building during project development.
4
+
The mechanisms used are regular community communication on the mailing list about progress, scheduled meetings for issue resolution and release triage, and regularly paced and communicated releases.
5
+
Releases are proposed and adopted or rejected using the usual [project governance](GOVERNANCE.md) rules and procedures.
6
+
7
+
An anti-pattern that we want to avoid is heavy development or discussions "late cycle" around major releases.
8
+
We want to build a community that is involved and communicates consistently through all releases instead of relying on "silent periods" as a judge of stability.
9
+
10
+
## Parallel releases
11
+
12
+
A single project MAY consider several motions to release in parallel.
13
+
However each motion to release after the initial 0.1.0 MUST be based on a previous release that has already landed.
14
+
15
+
For example, runtime-spec maintainers may propose a v1.0.0-rc2 on the 1st of the month and a v0.9.1 bugfix on the 2nd of the month.
16
+
They may not propose a v1.0.0-rc3 until the v1.0.0-rc2 is accepted (on the 7th if the vote initiated on the 1st passes).
17
+
18
+
## Specifications
19
+
20
+
The OCI maintains three categories of projects: specifications, applications, and conformance-testing tools.
21
+
However, specification releases have special restrictions in the [OCI charter][charter]:
22
+
23
+
* They are the target of backwards compatibility (§7.g), and
24
+
* They are subject to the OFWa patent grant (§8.d and e).
25
+
26
+
To avoid unfortunate side effects (onerous backwards compatibity requirements or Member resignations), the following additional procedures apply to specification releases:
27
+
28
+
### Planning a release
29
+
30
+
Every OCI specification project SHOULD hold meetings that involve maintainers reviewing pull requests, debating outstanding issues, and planning releases.
31
+
This meeting MUST be advertised on the project README and MAY happen on a phone call, video conference, or on IRC.
32
+
Maintainers MUST send updates to the [email protected] with results of these meetings.
33
+
34
+
Before the specification reaches v1.0.0, the meetings SHOULD be weekly.
35
+
Once a specification has reached v1.0.0, the maintainers may alter the cadence, but a meeting MUST be held within four weeks of the previous meeting.
36
+
37
+
The release plans, corresponding milestones and estimated due dates MUST be published on GitHub (e.g. https://github.com/opencontainers/runtime-spec/milestones).
38
+
GitHub milestones and issues are only used for community organization and all releases MUST follow the [project governance](GOVERNANCE.md) rules and procedures.
39
+
40
+
### Timelines
41
+
42
+
Specifications have a variety of different timelines in their lifecycle.
43
+
44
+
* Pre-v1.0.0 specifications SHOULD release on a monthly cadence to garner feedback.
45
+
* Major specification releases MUST release at least three release candidates spaced a minimum of one week apart.
46
+
This means a major release like a v1.0.0 or v2.0.0 release will take 1 month at minimum: one week for rc1, one week for rc2, one week for rc3, and one week for the major release itself.
47
+
Maintainers SHOULD strive to make zero breaking changes during this cycle of release candidates and SHOULD restart the three-candidate count when a breaking change is introduced.
48
+
For example if a breaking change is introduced in v1.0.0-rc2 then the series would end with v1.0.0-rc4 and v1.0.0.
49
+
- Minor and patch releases SHOULD be made on an as-needed basis.
0 commit comments