Merge pull request #642 from docker/init

Initial open-design proposal

CONTRIBUTING.md

@@ -0,0 +1,54 @@
+# Contributing to the registry
+
+## Are you having issues?
+
+Please first try any of these support forums before opening an issue:
+
+ * irc #docker on freenode (archives: [https://botbot.me/freenode/docker/])
+ * https://forums.docker.com/
+ * if your problem is with the "hub" (the website and other user-facing components), or about automated builds, then please direct your issues to https://support.docker.com
+
+## So, you found a bug?
+
+First check if your problem was already reported in the issue tracker.
+
+If it's already there, please refrain from adding "same here" comments - these don't add any value and are only adding useless noise. **Said comments will quite often be deleted at sight**. On the other hand, if you have any technical, relevant information to add, by all means do!
+
+Your issue is not there? Then please, create a ticket.
+
+If possible the following guidelines should be followed:
+
+ * try to come up with a minimal, simple to reproduce test-case
+ * try to add a title that describe succinctly the issue
+ * if you are running your own registry, please provide:
+  * registry version
+  * registry launch command used
+  * registry configuration
+  * registry logs
+ * in all cases:
+  * `docker version` and `docker info`
+  * run your docker daemon in debug mode (-D), and provide docker daemon logs 
+
+## You have a patch for a known bug, or a small correction?
+
+Basic github workflow (fork, patch, make sure the tests pass, PR).
+
+... and some simple rules to ensure quick merge:
+
+ * clearly point to the issue(s) you want to fix
+ * when possible, prefer multiple (smaller) PRs addressing individual issues over a big one trying to address multiple issues at once
+ * if you need to amend your PR following comments, squash instead of adding more commits
+
+## You want some shiny new feature to be added?
+
+Fork the project.
+
+Create a new proposal in the folder `open-design/specs`, named `DEP_MY_AWESOME_PROPOSAL.md`, using `open-design/specs/TEMPLATE.md` as a starting point.
+
+Then immediately submit this new file as a pull-request, in order to get early feedback.
+
+Eventually, you will have to update your proposal to accommodate the feedback you received.
+
+Usually, it's not advisable to start working too much on the implementation itself before the proposal receives sufficient feedback, since it can significantly altered (or rejected).
+
+Your implementation should then be submitted as a separate PR, that will be reviewed as well.

MAINTAINERS

@@ -0,0 +1,3 @@
+Solomon Hykes <solomon@docker.com> (@shykes)
+Olivier Gambier <olivier@docker.com> (@dmp42)
+Sam Alba <sam@docker.com> (@samalba)

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
+
+## 11/24/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