Initial open-design proposal

open-design/MANIFESTO.md

@@ -0,0 +1,20 @@
+# The "Distribution" project
+
+## What is this
+
+This is a part of the Docker project, or "primitive" that handles the "distribution" of images.
+
+### Punchline
+
+Pack. Sign. Ship. Store. Deliver. Verify.
+
+### Technical scope
+
+Distribution has tight relations with:
+
+ * libtrust, providing cryptographical primitives to handle image signing and verification
+ * image format, as transferred over the wire
+ * docker-registry, the server side component that allows storage and retrieval of packed images
+ * authentication and key management APIs, that are used to verify images and access storage services
+ * PKI infrastructure
+ * docker "pull/push client" code gluing all this together - network communication code, tarsum, etc

open-design/ROADMAP.md

@@ -0,0 +1,41 @@
+# Roadmap
+
+## 24/11/2014: alpha
+
+Design and code:
+
+- implements a basic configuration loading mechanism: https://github.com/docker/docker-registry/issues/646
+- storage API is frozen, implemented and used: https://github.com/docker/docker-registry/issues/616
+- REST API defined and partly implemented: https://github.com/docker/docker-registry/issues/634
+- basic logging: https://github.com/docker/docker-registry/issues/635
+- auth design is frozen: https://github.com/docker/docker-registry/issues/623
+
+Environment:
+
+- some good practice are in place and documented: https://github.com/docker/docker-registry/issues/657
+
+## 12/22/2014: beta
+
+Design and code:
+
+- feature freeze
+- mirroring defined: https://github.com/docker/docker-registry/issues/658
+- extension model defined: https://github.com/docker/docker-registry/issues/613
+
+Environment:
+
+- doc-driven approach: https://github.com/docker/docker-registry/issues/627
+
+## 01/12/2015: RC
+
+Design and code:
+
+- third party drivers and extensions
+- basic search extension
+- third-party layers garbage collection scripts
+- healthcheck endpoints: https://github.com/docker/docker-registry/issues/656
+- bugnsnag/new-relic support: https://github.com/docker/docker-registry/issues/680
+
+Environment:
+
+- exhaustive test-cases

open-design/specs/TEMPLATE.md

@@ -0,0 +1,52 @@
+# DEP #X: Awesome proposal
+
+## Scope
+
+This is related to "Foo" (eg: authentication/storage/extension/...).
+
+## Abstract
+
+This proposal suggests to add support for "bar".
+
+## User stories
+
+"I'm a Hub user, and 'bar' allows me to do baz1"
+
+"I'm a FOSS user running my private registry and 'bar' allows me to do baz2"
+
+"I'm a company running the registry and 'bar' allows me to do baz3"
+
+## Technology pre-requisites
+
+'bar' can be implemented using:
+
+ * foobar approach
+ * barfoo concurrent approach
+
+## Dependencies
+
+Project depends on baz to be completed (eg: docker engine support, or another registry proposal).
+
+## Technical proposal
+
+We are going to do foofoo alongside with some chunks of barbaz.
+
+## Roadmap
+
+ * YYYY-MM-DD: proposal submitted
+ * YYYY-MM-DD: proposal reviewed and updated
+ * YYYY-MM-DD: implementation started (WIP PR)
+ * YYYY-MM-DD: implementation complete ready for thorough review
+ * YYYY-MM-DD: final PR version
+ * YYYY-MM-DD: implementation merged
+
+## Editors
+
+Editors:
+
+ * my Company, or maybe just me
+
+Implementors:
+
+ * me and my buddies
+ * another team working on a different approach