projects: add umoci proposal

Signed-off-by: Aleksa Sarai <[email protected]>

README.md

@@ -1,6 +1,6 @@
 # Technical Oversight Board (TOB)
 
-The TOB is responsible for managing conflicts, violations of procedures or guidelines and any cross-project or high-level issues that cannot be resolved in the TDC for OCI Projects. The TOB shall also be responsible for adding, removing or reorganizing OCI Projects. 
+The TOB is responsible for managing conflicts, violations of procedures or guidelines and any cross-project or high-level issues that cannot be resolved in the TDC for OCI Projects. The TOB shall also be responsible for adding, removing or reorganizing OCI Projects.
 
 ## Members
 
@@ -26,6 +26,7 @@ https://groups.google.com/a/opencontainers.org/forum/#!forum/tob (tob@opencontai
 * [Image Format Spec](proposals/image-format)
 * [SELinux](proposals/selinux.md)
 * [Tools](proposals/tools.md)
+* [umoci](proposals/umoci.md)
 
 ## Voting
 

proposals/umoci.md

@@ -0,0 +1,108 @@
+# OCI umoci Project Proposal #
+
+## Abstract ##
+The need for a "works out of the box" image tool that is supported by OCI has been clear for several years.
+umoci was initially developed to fulfil this requirement, and after several years of development and wide-spread production usage, we feel it is time to include it within the OCI.
+The following proposal outlines how this would be achieved.
+
+## Proposal ##
+Change the ownership of the existing umoci project from openSUSE:
+
+  https://github.com/openSUSE/umoci
+
+And move it inside the `opencontainers` organisation:
+
+  https://github.com/opencontainers/umoci
+
+The import paths will correspondingly be "github.com/opencontainers/umoci" (umoci does have some Go API users, but since the project will be renamed -- and GitHub will add a redirect -- there will be no significant downstream impact of the change).
+In future we may opt to use vanity imports (such as "umo.ci/cmd/umoci").
+
+In addition, a sub-tree merge (to preserve the history) of the existing image-tools repository
+
+  https://github.com/opencontainers/image-tools
+
+will be done into umoci.
+This will be done to allow the archival of the oci-image-tools repository, as the primary features it has over umoci (specification validation) will be maintained within umoci instead.
+The purpose of this change is to avoid confusion as to which OCI image tool the OCI is shepherding.
+
+The project's domain "umo.ci" could also be transferred to the Linux Foundation so that it can be managed by someone other than the maintainers (though maintainers should still have necessary administrative access to maintain the website).
+
+### Initial Maintainers ###
+Initial maintainers of the umoci project would be:
+
+* Aleksa Sarai <[email protected]> (@cyphar)
+* Tycho Andersen <[email protected]> (@tych0)
+
+### Code of Conduct ###
+This project would incorporate (by reference) the OCI [Code of Conduct][code-of-conduct].
+
+[code-of-conduct]: https://github.com/opencontainers/org/blob/master/CODE_OF_CONDUCT.md
+
+### Governance and Releases ###
+This project would incorporate the Governance and Releases processes from the OCI project template: https://github.com/opencontainers/project-template.
+
+It should be noted that since umoci is not a specification, it is not bound by the ordinary quorum and voting rules for specification release.
+As such, new versions will be released as regularly as needed without the need for a quorum vote.
+This is to avoid the serious delays in releases encountered within the `runc` project.
+
+Until there are enough additional maintainers, PRs will be merged with only one maintainer LGTM required.
+Maintainers are encouraged to not merge their own PRs immediately (preferably waiting at least 24 to 48 hours to allow another maintainer to review it), but this is not a strict rule.
+
+### Project Communications ###
+The proposed project would continue to use existing channels in use by the OCI developer community for communication including:
+
+ * GitHub for issues and pull requests.
+ * The [`[email protected]`][oci-ml] email list.
+ * The weekly OCI developer community conference call.
+ * The `#opencontainers` IRC channel on Freenode.
+ * The [OCI Slack workspace][oci-slack].
+ * The [OCI Matrix Room][oci-matrix].
+
+[oci-ml]: mailto:[email protected]
+[oci-slack]: https://opencontainers.slack.com/
+[oci-matrix]: https://matrix.to/#/#opencontainers:matrix.org
+
+### Roadmap ###
+umoci still has a fairly large scope of work, and this work would continue under OCI.
+Examples of such work include:
+
+ * Hookable execution to allow for custom storage drivers to be defined by users (to avoid the maintainence overhead of supporting such drivers within umoci).
+ * Security hardening by porting umoci to libpathrs.
+ * Re-thinking the method by which images are referenced in the command-line.
+ * Expanded support for configuring descriptor annotations in arbitrarily-structured OCI metadata trees.
+ * Committing to a stable Go API and releasing a 1.0 of the project.
+ * Experimenal design work for a new OCI image-spec layer format (code-named "OCIv2").
+
+Additionally, merging the validation code into umoci (either as a sub-project, or as a sub-command of the main `umoci` tool) would be work that should be carried out as soon as this proposal is actioned.
+
+## Frequently Asked Questions (FAQ)
+*Q: Does this change the OCI Charter or Scope Table?*
+A: Yes, this will add an additional row to the [OCI Scope Table][oci-scope-table], which does not currently include any mention of generic OCI image tooling.
+We feel that this is a natural extension of the OCI project's goals, and is very similar to `runc` in its justification for being included in the scope of OCI.
+This proposal does not intend to amend the [OCI Charter][oci-charter].
+
+[oci-scope-table]: https://www.opencontainers.org/about/oci-scope-table
+[oci-charter]: https://www.opencontainers.org/about/governance
+
+*Q: What about image-tools?*
+A: The original intention of umoci was to be a wrapper around the OCI image-tools and slowly upstream the work.
+Unfortunately, in the past 3 years, the image-tools project has not developed at a consistent pace -- and umoci works today and is fairly widely used.
+It is far more important that the OCI provide a solid "works out of the box" image manipulation tool, and umoci is (in our view) the best candidate for this role.
+However, the work done by the image-tools contributors and maintainers is clearly valuable and thus by sub-tree merging the project (and continuing maintainence of the features not present in umoci) we can continue the legacy of that work.
+
+*Q: Why bless this tool in particular over others?*
+A: umoci is the only OCI image tool which was designed to be usable as a component to build other image-building tools.
+This has proven to be the case, with several tools ([KIWI][kiwi], [stacker][stacker], and several others) being built on top of umoci.
+In addition, umoci has been used by the [LXC project][lxc-oci] to support OCI-based images from *outside* the OCI ecosystem, something that was only reasonable because of umoci's unopinionated stance on images.
+
+[kiwi]: https://osinside.github.io/kiwi/
+[stacker]: https://github.com/anuvu/stacker
+[lxc-oci]: https://github.com/lxc/lxc/blob/lxc-3.2.1/templates/lxc-oci.in
+
+*Q: How do we avoid the `runc` issue with implementation-specific quirks becoming a de-facto standard?*
+A: When developing new features in umoci (which are within the scope of the image-spec), a strong effort will be made to include those features in the upstream specification.
+The scope of the image-spec is thankfully smaller than the runtime-spec, so this should not be as much of a concern as with `runc`.
+However, the maintainers will be mindful of the issue and will make use of their experiences working on `runc` and the runtime-spec to avoid this situation occurring with umoci and the image-spec.
+
+*Q: Who are the other target users of umoci?*
+A: End-users who want a simple tool to deal with OCI images, and developers of image-building tools that want a tried and tested implemented of the OCI image format.