Merge pull request #300 from duglin/patch-1

Update ROADMAP.md

ROADMAP.md

@@ -17,12 +17,12 @@ Although OCI doesn't define a transport method we should have a cryptographic di
 
 *Owner:* philips
 
-### Review the need for runtime.json
+### Review the need for runtime.json (Target release: v0.3.0)
 
 There are some discussions about having `runtime.json` being optional for containers and specifying defaults.
 Runtimes would use this standard set of defaults for containers and `runtime.json` would provide overrides for fine tuning of these extra host or platform specific settings.
 
-*Owner:*
+*Owner:* mrunalp
 
 ### Define Container Lifecycle
 
@@ -31,38 +31,48 @@ The lifecycle events of a container also help identify areas to implement hooks
 
 *Owner:* mrunalp
 
-### Define Standard Container Actions
+### Define Standard Container Actions (Target release: v0.3.0)
 
 Define what type of actions a runtime can perform on a container without imposing hardships on authors of platforms that do not support advanced options.
 
-*Owner:*
+*Owner:* duglin
 
 ### Clarify rootfs requirement in base spec
 
 Is the rootfs needed or should it just be expected in the bundle without having a field in the spec?
 
+Resolution: keep it as is - user definable
+Submit as a different PR
+For reference: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/6ZKMNWujDhU
+
 *Owner:*
 
 ### Container Definition
 
 Define what a software container is and its attributes in a cross platform way.
 
-*Owner:*
+Could be solved by lifecycle/ops and create/start split discussions
+
+*Owner:* vishh & duglin
 
 ### Live Container Updates
 
 Should we allow dynamic container updates to runtime options?
 
-*Owner:* vishh
+Proposal: make it an optional feature
+
+*Owner:* hqhq (was vishh) robdolinms, bcorrie
 
 ### Protobuf Config
 
 We currently have only one language binding for the spec and that is Go.
 If we change the specs format in the respository to be something like protobuf then the generation for multiple language bindings become effortless.
 
+Not going to do it
+
 *Owner:* vbatts
 
-### Validation Tooling
+### Validation Tooling (Target release: v0.3.0)
 
 Provide validation tooling for compliance with OCI spec and runtime environment.
 
@@ -78,12 +88,18 @@ Provide a testing framework for compliance with OCI spec and runtime environment
 
 Decide on a robust versioning schema for the spec as it evolves.
 
-*Owner:*
+Resolved but release process could evolve. Resolved for v0.2.0, expect to revisit near v1.0.0
+
+*Owner:* vbatts
 
 ### Printable/Compiled Spec
 
 Regardless of how the spec is written, ensure that it is easy to read and follow for first time users.
 
+Part of this is resolved.  Produces an html & pdf.
+Done
+Would be nice to publish to the OCI web site as part of our release process.
+
 *Owner:* vbatts
 
 ### Base Config Compatibility
@@ -96,9 +112,11 @@ Systems:
 * Windows
 * Linux
 
-*Owner:*
+*Owner:* robdolinms as lead coordinator
 
 ### Full Lifecycle Hooks
 Ensure that we have lifecycle hooks in the correct places with full coverage over the container lifecycle.
 
+Will probably go away with Vish's work on splitting create and start, and if we have exec.
+
 *Owner:*