From e31b7d8d9a30d9138819f54cbe7744c908e49396 Mon Sep 17 00:00:00 2001 From: Olivier Gambier Date: Tue, 21 Oct 2014 13:33:28 -0700 Subject: [PATCH 1/2] Initial open-design proposal --- CONTRIBUTING.md | 55 +++++++++++++++++++++++++++++++++++ MAINTAINERS | 3 ++ open-design/MANIFESTO.md | 20 +++++++++++++ open-design/ROADMAP.md | 41 ++++++++++++++++++++++++++ open-design/specs/TEMPLATE.md | 52 +++++++++++++++++++++++++++++++++ 5 files changed, 171 insertions(+) create mode 100644 CONTRIBUTING.md create mode 100644 MAINTAINERS create mode 100644 open-design/MANIFESTO.md create mode 100644 open-design/ROADMAP.md create mode 100644 open-design/specs/TEMPLATE.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..3a706204 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,55 @@ +# 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 technical, relevant informations 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 succintly 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 adressing individual issues over a big one trying to adress 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 with the feedback you received. + +Usually, it's advised not 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. diff --git a/MAINTAINERS b/MAINTAINERS new file mode 100644 index 00000000..2292fb99 --- /dev/null +++ b/MAINTAINERS @@ -0,0 +1,3 @@ +Solomon Hykes (@shykes) +Olivier Gambier (@dmp42) +Sam Alba (@samalba) diff --git a/open-design/MANIFESTO.md b/open-design/MANIFESTO.md new file mode 100644 index 00000000..f3cd03da --- /dev/null +++ b/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 diff --git a/open-design/ROADMAP.md b/open-design/ROADMAP.md new file mode 100644 index 00000000..3f0c042b --- /dev/null +++ b/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 diff --git a/open-design/specs/TEMPLATE.md b/open-design/specs/TEMPLATE.md new file mode 100644 index 00000000..a87ea61e --- /dev/null +++ b/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 \ No newline at end of file From 2b7b8fa2ca5ac9ffe4ad420620b4e2ce0e03f83b Mon Sep 17 00:00:00 2001 From: Olivier Gambier Date: Tue, 21 Oct 2014 13:33:28 -0700 Subject: [PATCH 2/2] Initial open-design proposal --- CONTRIBUTING.md | 15 +++++++-------- open-design/ROADMAP.md | 2 +- 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3a706204..fb7fcf78 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -12,14 +12,14 @@ Please first try any of these support forums before opening an issue: 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 technical, relevant informations to add, by all means do! +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 succintly the issue + * 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 @@ -27,8 +27,7 @@ If possible the following guidelines should be followed: * registry logs * in all cases: * `docker version` and `docker info` - * run your docker daemon in debug mode (-D), and provide docker daemon logs - + * 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? @@ -37,19 +36,19 @@ 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 adressing individual issues over a big one trying to adress multiple issues at once + * 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. +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 with the feedback you received. +Eventually, you will have to update your proposal to accommodate the feedback you received. -Usually, it's advised not to start working too much on the implementation itself before the proposal receives sufficient feedback, since it can significantly altered (or rejected). +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. diff --git a/open-design/ROADMAP.md b/open-design/ROADMAP.md index 3f0c042b..54e244ad 100644 --- a/open-design/ROADMAP.md +++ b/open-design/ROADMAP.md @@ -1,6 +1,6 @@ # Roadmap -## 24/11/2014: alpha +## 11/24/2014: alpha Design and code: