Merge pull request #642 from docker/init

Initial open-design proposal
This commit is contained in:
Stephen Day 2014-11-10 10:47:17 -08:00
commit 364b11e876
5 changed files with 170 additions and 0 deletions

54
CONTRIBUTING.md Normal file
View file

@ -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.

3
MAINTAINERS Normal file
View file

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

20
open-design/MANIFESTO.md Normal file
View file

@ -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

41
open-design/ROADMAP.md Normal file
View file

@ -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

View file

@ -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