├── CODEOWNERS ├── CONTRIBUTING.md ├── GOVERNANCE.md ├── LICENSE ├── MAINTAINERS ├── MAINTAINERS_GUIDE.md ├── README.md └── RELEASES.md /CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @maintainer1 @maintainer2 @maintainer3 2 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contribution Guidelines 2 | 3 | Development happens on GitHub. 4 | Issues are used for bugs and actionable items and longer discussions can happen on the [mailing list](#mailing-list). 5 | 6 | The content of this repository is licensed under the [Apache License, Version 2.0](LICENSE). 7 | 8 | ## Code of Conduct 9 | 10 | Participation in the Open Container community is governed by [Open Container Code of Conduct][code-of-conduct]. 11 | 12 | ## Meetings 13 | 14 | The contributors and maintainers of all OCI projects have monthly meetings at 2:00 PM (USA Pacific) on the first Wednesday of every month. 15 | There is an [iCalendar][rfc5545] format for the meetings [here][meeting.ics]. 16 | Everyone is welcome to participate via [UberConference web][UberConference] or audio-only: +1 415 968 0849 (no PIN needed). 17 | An initial agenda will be posted to the [mailing list](#mailing-list) in the week before each meeting, and everyone is welcome to propose additional topics or suggest other agenda alterations there. 18 | Minutes from past meetings are archived [here][minutes]. 19 | 20 | ## Mailing list 21 | 22 | You can subscribe and browse the mailing list on [Google Groups][mailing-list]. 23 | 24 | ## IRC 25 | 26 | OCI discussion happens on #opencontainers on [Freenode][] ([logs][irc-logs]). 27 | 28 | ## Git 29 | 30 | ### Security issues 31 | 32 | If you are reporting a security issue, do not create an issue or file a pull 33 | request on GitHub. Instead, disclose the issue responsibly by sending an email 34 | to security@opencontainers.org (which is inhabited only by the maintainers of 35 | the various OCI projects). 36 | 37 | ### Pull requests are always welcome 38 | 39 | We are always thrilled to receive pull requests, and do our best to 40 | process them as fast as possible. Not sure if that typo is worth a pull 41 | request? Do it! We will appreciate it. 42 | 43 | If your pull request is not accepted on the first try, don't be 44 | discouraged! If there's a problem with the implementation, hopefully you 45 | received feedback on what to improve. 46 | 47 | We're trying very hard to keep the project lean and focused. We don't want it 48 | to do everything for everybody. This means that we might decide against 49 | incorporating a new feature. 50 | 51 | ### Conventions 52 | 53 | Fork the repo and make changes on your fork in a feature branch. 54 | For larger bugs and enhancements, consider filing a leader issue or mailing-list thread for discussion that is independent of the implementation. 55 | Small changes or changes that have been discussed on the [project mailing list](#mailing-list) may be submitted without a leader issue. 56 | 57 | If the project has a test suite, submit unit tests for your changes. Take a 58 | look at existing tests for inspiration. Run the full test suite on your branch 59 | before submitting a pull request. 60 | 61 | Update the documentation when creating or modifying features. Test 62 | your documentation changes for clarity, concision, and correctness, as 63 | well as a clean documentation build. 64 | 65 | Pull requests descriptions should be as clear as possible and include a 66 | reference to all the issues that they address. 67 | 68 | Commit messages must start with a capitalized and short summary 69 | written in the imperative, followed by an optional, more detailed 70 | explanatory text which is separated from the summary by an empty line. 71 | 72 | Code review comments may be added to your pull request. Discuss, then make the 73 | suggested modifications and push additional commits to your feature branch. Be 74 | sure to post a comment after pushing. The new commits will show up in the pull 75 | request automatically, but the reviewers will not be notified unless you 76 | comment. 77 | 78 | Before the pull request is merged, make sure that you squash your commits into 79 | logical units of work using `git rebase -i` and `git push -f`. After every 80 | commit the test suite (if any) should be passing. Include documentation changes 81 | in the same commit so that a revert would remove all traces of the feature or 82 | fix. 83 | 84 | Commits that fix or close an issue should include a reference like `Closes #XXX` 85 | or `Fixes #XXX`, which will automatically close the issue when merged. 86 | 87 | ### Sign your work 88 | 89 | The sign-off is a simple line at the end of the explanation for the 90 | patch, which certifies that you wrote it or otherwise have the right to 91 | pass it on as an open-source patch. The rules are pretty simple: if you 92 | can certify the below (from [developercertificate.org][]): 93 | 94 | ``` 95 | Developer Certificate of Origin 96 | Version 1.1 97 | 98 | Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 99 | 1 Letterman Drive 100 | Suite D4700 101 | San Francisco, CA, 94129 102 | 103 | Everyone is permitted to copy and distribute verbatim copies of this 104 | license document, but changing it is not allowed. 105 | 106 | 107 | Developer's Certificate of Origin 1.1 108 | 109 | By making a contribution to this project, I certify that: 110 | 111 | (a) The contribution was created in whole or in part by me and I 112 | have the right to submit it under the open source license 113 | indicated in the file; or 114 | 115 | (b) The contribution is based upon previous work that, to the best 116 | of my knowledge, is covered under an appropriate open source 117 | license and I have the right under that license to submit that 118 | work with modifications, whether created in whole or in part 119 | by me, under the same open source license (unless I am 120 | permitted to submit under a different license), as indicated 121 | in the file; or 122 | 123 | (c) The contribution was provided directly to me by some other 124 | person who certified (a), (b) or (c) and I have not modified 125 | it. 126 | 127 | (d) I understand and agree that this project and the contribution 128 | are public and that a record of the contribution (including all 129 | personal information I submit with it, including my sign-off) is 130 | maintained indefinitely and may be redistributed consistent with 131 | this project or the open source license(s) involved. 132 | ``` 133 | 134 | then you just add a line to every git commit message: 135 | 136 | Signed-off-by: Joe Smith 137 | 138 | using your real name (sorry, no pseudonyms or anonymous contributions.) 139 | 140 | You can add the sign off when creating the git commit via `git commit -s`. 141 | 142 | [code-of-conduct]: https://github.com/opencontainers/tob/blob/d2f9d68c1332870e40693fe077d311e0742bc73d/code-of-conduct.md 143 | [developercertificate.org]: http://developercertificate.org/ 144 | [Freenode]: https://freenode.net/ 145 | [irc-logs]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/ 146 | [mailing-list]: https://groups.google.com/a/opencontainers.org/forum/#!forum/dev 147 | [meeting.ics]: https://github.com/opencontainers/runtime-spec/blob/master/meeting.ics 148 | [minutes]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/ 149 | [rfc5545]: https://tools.ietf.org/html/rfc5545 150 | [UberConference]: https://www.uberconference.com/opencontainers 151 | -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | # Project governance 2 | 3 | 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 dev@opencontainers.org 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 dev@opencontainers.org 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 feedback), 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 | ## Amendments 35 | 36 | The [project governance](#project-governance) rules and procedures MAY be amended or replaced using the procedures themselves. 37 | The MAINTAINERS of this project governance document is the total set of MAINTAINERS from all Open Containers projects (go-digest, image-spec, image-tools, runC, runtime-spec, runtime-tools, and selinux). 38 | 39 | ## Subject templates 40 | 41 | Maintainers are busy and get lots of email. 42 | To make project proposals recognizable, proposed motions SHOULD use the following subject templates. 43 | 44 | ### Proposing a motion 45 | 46 | > [{project} VOTE]: {motion description} (closes {end of voting window}) 47 | 48 | For example: 49 | 50 | > [runtime-spec VOTE]: Tag 0647920 as 1.0.0-rc (closes 2016-06-03 20:00 UTC) 51 | 52 | ### Tallying results 53 | 54 | After voting closes, a maintainer SHOULD post a tally to the motion thread with a subject template like: 55 | 56 | > [{project} {status}]: {motion description} (+{LGTMs} -{REJECTs} #{ABSTAINs}) 57 | 58 | Where `{status}` is either `adopted` or `rejected`. 59 | For example: 60 | 61 | > [runtime-spec adopted]: Tag 0647920 as 1.0.0-rc (+6 -0 #3) 62 | 63 | [charter]: https://www.opencontainers.org/about/governance 64 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "{}" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright {yyyy} {name of copyright owner} 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /MAINTAINERS: -------------------------------------------------------------------------------- 1 | This meta-project is maintained by the union of MAINTAINERS for all OCI Projects [1]. 2 | 3 | Other OCI Projects should list one maintainer per line, with a name, email address, and GitHub username: 4 | 5 | Random J Developer (@RandomJDeveloperExample) 6 | A. U. Thor (@AUThorExample) 7 | 8 | [1]: https://github.com/opencontainers/ 9 | -------------------------------------------------------------------------------- /MAINTAINERS_GUIDE.md: -------------------------------------------------------------------------------- 1 | ## Introduction 2 | 3 | Dear maintainer. Thank you for investing the time and energy to help 4 | make this project as useful as possible. Maintaining a project is difficult, 5 | sometimes unrewarding work. Sure, you will get to contribute cool 6 | features to the project. But most of your time will be spent reviewing, 7 | cleaning up, documenting, answering questions, justifying design 8 | decisions - while everyone has all the fun! But remember - the quality 9 | of the maintainers work is what distinguishes the good projects from the 10 | great. So please be proud of your work, even the unglamourous parts, 11 | and encourage a culture of appreciation and respect for *every* aspect 12 | of improving the project - not just the hot new features. 13 | 14 | This document is a manual for maintainers old and new. It explains what 15 | is expected of maintainers, how they should work, and what tools are 16 | available to them. 17 | 18 | This is a living document - if you see something out of date or missing, 19 | speak up! 20 | 21 | ## What are a maintainer's responsibilities? 22 | 23 | It is every maintainer's responsibility to: 24 | 25 | * Expose a clear roadmap for improving their component. 26 | * Deliver prompt feedback and decisions on pull requests. 27 | * Be available to anyone with questions, bug reports, criticism etc. on their component. 28 | This includes IRC and GitHub issues and pull requests. 29 | * Make sure their component respects the philosophy, design and roadmap of the project. 30 | 31 | ## How are decisions made? 32 | 33 | This project is an open-source project with an open design philosophy. This 34 | means that the repository is the source of truth for EVERY aspect of the 35 | project, including its philosophy, design, roadmap and APIs. *If it's 36 | part of the project, it's in the repo. It's in the repo, it's part of 37 | the project.* 38 | 39 | As a result, all decisions can be expressed as changes to the 40 | repository. An implementation change is a change to the source code. An 41 | API change is a change to the API specification. A philosophy change is 42 | a change to the philosophy manifesto. And so on. 43 | 44 | All decisions affecting this project, big and small, follow the same procedure: 45 | 46 | 1. Discuss a proposal on the [mailing list](CONTRIBUTING.md#mailing-list). 47 | Anyone can do this. 48 | 2. Open a pull request. 49 | Anyone can do this. 50 | 3. Discuss the pull request. 51 | Anyone can do this. 52 | 4. Endorse (`LGTM`) or oppose (`Rejected`) the pull request. 53 | The relevant maintainers do this (see below [Who decides what?](#who-decides-what)). 54 | Changes that affect project management (changing policy, cutting releases, etc.) are [proposed and voted on the mailing list](GOVERNANCE.md). 55 | 5. Merge or close the pull request. 56 | The relevant maintainers do this. 57 | 58 | ### I'm a maintainer, should I make pull requests too? 59 | 60 | Yes. Nobody should ever push to master directly. All changes should be 61 | made through a pull request. 62 | 63 | ## Who decides what? 64 | 65 | All decisions are pull requests, and the relevant maintainers make 66 | decisions by accepting or refusing the pull request. Review and acceptance 67 | by anyone is denoted by adding a comment in the pull request: `LGTM`. 68 | However, only currently listed `MAINTAINERS` are counted towards the required 69 | two LGTMs. In addition, if a maintainer has created a pull request, they cannot 70 | count toward the two LGTM rule (to ensure equal amounts of review for every pull 71 | request, no matter who wrote it). 72 | 73 | Overall the maintainer system works because of mutual respect. 74 | The maintainers trust one another to act in the best interests of the project. 75 | Sometimes maintainers can disagree and this is part of a healthy project to represent the points of view of various people. 76 | In the case where maintainers cannot find agreement on a specific change, maintainers should use the [governance procedure](GOVERNANCE.md) to attempt to reach a consensus. 77 | 78 | ### How are maintainers added? 79 | 80 | The best maintainers have a vested interest in the project. Maintainers 81 | are first and foremost contributors that have shown they are committed to 82 | the long term success of the project. Contributors wanting to become 83 | maintainers are expected to be deeply involved in contributing code, 84 | pull request review, and triage of issues in the project for more than two months. 85 | 86 | Just contributing does not make you a maintainer, it is about building trust with the current maintainers of the project and being a person that they can depend on to act in the best interest of the project. 87 | The final vote to add a new maintainer should be approved by the [governance procedure](GOVERNANCE.md). 88 | 89 | ### How are maintainers removed? 90 | 91 | When a maintainer is unable to perform the [required duties](#what-are-a-maintainers-responsibilities) they can be removed by the [governance procedure](GOVERNANCE.md). 92 | Issues related to a maintainer's performance should be discussed with them among the other maintainers so that they are not surprised by a pull request removing them. 93 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OCI Project Template 2 | 3 | Useful boilerplate and organizational information for all OCI projects. 4 | 5 | * README (this file) 6 | * [The Apache License, Version 2.0](LICENSE) 7 | * [A list of maintainers](MAINTAINERS) 8 | * [Maintainer guidelines](MAINTAINERS_GUIDE.md) 9 | * [Contributor guidelines](CONTRIBUTING.md) 10 | * [Project governance](GOVERNANCE.md) 11 | * [Release procedures](RELEASES.md) 12 | -------------------------------------------------------------------------------- /RELEASES.md: -------------------------------------------------------------------------------- 1 | # Releases 2 | 3 | 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 dev@opencontainers.org 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. 50 | 51 | [charter]: https://www.opencontainers.org/about/governance 52 | --------------------------------------------------------------------------------