kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity

Merge pull request #4413 from jamtur01/exemption

Browse source 
Added documentation (and some cleanup) around small patch exemptions
This commit is contained in:
Sven Dowideit 2014-03-04 09:10:37 +10:00
commit fca4cf6f0a
3 changed files with 64 additions and 35 deletions
Download patch file Download diff file Expand all files Collapse all files

11
CONTRIBUTING.md
View file

@ -117,7 +117,7 @@ to indicate acceptance.
A change requires LGTMs from an absolute majority of the maintainers of each A change requires LGTMs from an absolute majority of the maintainers of each
component affected. For example, if a change affects docs/ and registry/, it component affected. For example, if a change affects docs/ and registry/, it
needs an absolute majority from the maintainers of docs/ AND, separately, an needs an absolute majority from the maintainers of docs/ AND, separately, an
absolute majority of the maintainers of registry absolute majority of the maintainers of registry.
For more details see [MAINTAINERS.md](hack/MAINTAINERS.md) For more details see [MAINTAINERS.md](hack/MAINTAINERS.md)
@ -170,10 +170,15 @@ curl -o .git/hooks/prepare-commit-msg https://raw.github.com/dotcloud/docker/mas
* Note: the above script expects to find your GitHub user name in ``git config --get github.user`` * Note: the above script expects to find your GitHub user name in ``git config --get github.user``
#### Small patch exception
There are several exceptions to the signing requirement. Currently these are:
* Your patch fixes spelling or grammar errors.
* Your patch is a single line change to documentation.
If you have any questions, please refer to the FAQ in the [docs](http://docs.docker.io) If you have any questions, please refer to the FAQ in the [docs](http://docs.docker.io)
### How can I become a maintainer? ### How can I become a maintainer?
* Step 1: learn the component inside out * Step 1: learn the component inside out

8
docs/sources/faq.rst
View file

@ -189,10 +189,15 @@ How do I report a security issue with Docker?
You can learn about the project's security policy `here <http://www.docker.io/security/>`_ You can learn about the project's security policy `here <http://www.docker.io/security/>`_
and report security issues to this `mailbox <mailto:security@docker.com>`_. and report security issues to this `mailbox <mailto:security@docker.com>`_.
Why do I need to sign my commits to Docker with the DCO?
........................................................
Please read `our blog post <http://blog.docker.io/2014/01/docker-code-contributions-require-developer-certificate-of-origin/>`_ on the introduction of the DCO.
Can I help by adding some questions and answers? Can I help by adding some questions and answers?
................................................ ................................................
Definitely! You can fork `the repo`_ and edit the documentation sources. Definitely! You can fork `the repo`_ and edit the documentation sources.
Where can I find more answers? Where can I find more answers?
@ -216,5 +221,4 @@ Where can I find more answers?
.. _Ask questions on Stackoverflow: http://stackoverflow.com/search?q=docker .. _Ask questions on Stackoverflow: http://stackoverflow.com/search?q=docker
.. _Join the conversation on Twitter: http://twitter.com/docker .. _Join the conversation on Twitter: http://twitter.com/docker
Looking for something else to read? Checkout the :ref:`hello_world` example. Looking for something else to read? Checkout the :ref:`hello_world` example.

80
hack/MAINTAINERS.md
View file

@ -1,22 +1,24 @@
# The Docker maintainer manual # The Docker Maintainer manual
## Introduction ## Introduction
Dear maintainer. Thank you for investing the time and energy to help make Docker as Dear maintainer. Thank you for investing the time and energy to help
useful as possible. Maintaining a project is difficult, sometimes unrewarding work. make Docker as useful as possible. Maintaining a project is difficult,
Sure, you will get to contribute cool features to the project. But most of your time sometimes unrewarding work. Sure, you will get to contribute cool
will be spent reviewing, cleaning up, documenting, answering questions, justifying features to the project. But most of your time will be spent reviewing,
design decisions - while everyone has all the fun! But remember - the quality of the cleaning up, documenting, answering questions, justifying design
maintainers work is what distinguishes the good projects from the great. decisions - while everyone has all the fun! But remember - the quality
So please be proud of your work, even the unglamourous parts, and encourage a culture of the maintainers work is what distinguishes the good projects from the
of appreciation and respect for *every* aspect of improving the project - not just the great. So please be proud of your work, even the unglamourous parts,
hot new features. and encourage a culture of appreciation and respect for *every* aspect
of improving the project - not just the hot new features.
This document is a manual for maintainers old and new. It explains what is expected of This document is a manual for maintainers old and new. It explains what
maintainers, how they should work, and what tools are available to them. is expected of maintainers, how they should work, and what tools are
available to them.
This is a living document - if you see something out of date or missing, speak up!
This is a living document - if you see something out of date or missing,
speak up!
## What are a maintainer's responsibility? ## What are a maintainer's responsibility?
@ -24,19 +26,26 @@ It is every maintainer's responsibility to:
* 1) Expose a clear roadmap for improving their component. * 1) Expose a clear roadmap for improving their component.
* 2) Deliver prompt feedback and decisions on pull requests. * 2) Deliver prompt feedback and decisions on pull requests.
* 3) Be available to anyone with questions, bug reports, criticism etc. on their component. This includes irc, github requests and the mailing list. * 3) Be available to anyone with questions, bug reports, criticism etc.
* 4) Make sure their component respects the philosophy, design and roadmap of the project. on their component. This includes IRC, GitHub requests and the mailing
list.
* 4) Make sure their component respects the philosophy, design and
roadmap of the project.
## How are decisions made? ## How are decisions made?
Short answer: with pull requests to the docker repository. Short answer: with pull requests to the docker repository.
Docker is an open-source project with an open design philosophy. This means that the repository is the source of truth for EVERY aspect of the project, Docker is an open-source project with an open design philosophy. This
including its philosophy, design, roadmap and APIs. *If it's part of the project, it's in the repo. It's in the repo, it's part of the project.* means that the repository is the source of truth for EVERY aspect of the
project, including its philosophy, design, roadmap and APIs. *If it's
part of the project, it's in the repo. It's in the repo, it's part of
the project.*
As a result, all decisions can be expressed as changes to the repository. An implementation change is a change to the source code. An API change is a change to As a result, all decisions can be expressed as changes to the
the API specification. A philosophy change is a change to the philosophy manifesto. And so on. repository. An implementation change is a change to the source code. An
API change is a change to the API specification. A philosophy change is
a change to the philosophy manifesto. And so on.
All decisions affecting docker, big and small, follow the same 3 steps: All decisions affecting docker, big and small, follow the same 3 steps:
@ -49,25 +58,36 @@ All decisions affecting docker, big and small, follow the same 3 steps:
## Who decides what? ## Who decides what?
So all decisions are pull requests, and the relevant maintainer makes the decision by accepting or refusing the pull request. So all decisions are pull requests, and the relevant maintainer makes
But how do we identify the relevant maintainer for a given pull request? the decision by accepting or refusing the pull request. But how do we
identify the relevant maintainer for a given pull request?
Docker follows the timeless, highly efficient and totally unfair system known as [Benevolent dictator for life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), Docker follows the timeless, highly efficient and totally unfair system
with yours truly, Solomon Hykes, in the role of BDFL. known as [Benevolent dictator for
This means that all decisions are made by default by me. Since making every decision myself would be highly un-scalable, in practice decisions are spread across multiple maintainers. life](http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life), with
yours truly, Solomon Hykes, in the role of BDFL. This means that all
decisions are made by default by Solomon. Since making every decision
myself would be highly un-scalable, in practice decisions are spread
across multiple maintainers.
The relevant maintainer for a pull request is assigned in 3 steps: The relevant maintainer for a pull request is assigned in 3 steps:
* Step 1: Determine the subdirectory affected by the pull request. This might be src/registry, docs/source/api, or any other part of the repo. * Step 1: Determine the subdirectory affected by the pull request. This
might be `src/registry`, `docs/source/api`, or any other part of the repo.
* Step 2: Find the MAINTAINERS file which affects this directory. If the directory itself does not have a MAINTAINERS file, work your way up the repo hierarchy until you find one. * Step 2: Find the `MAINTAINERS` file which affects this directory. If the
directory itself does not have a `MAINTAINERS` file, work your way up
the repo hierarchy until you find one.
* Step 3: The first maintainer listed is the primary maintainer. The pull request is assigned to him. He may assign it to other listed maintainers, at his discretion. * Step 3: The first maintainer listed is the primary maintainer. The
pull request is assigned to him. He may assign it to other listed
maintainers, at his discretion.
### I'm a maintainer, should I make pull requests too? ### I'm a maintainer, should I make pull requests too?
Yes. Nobody should ever push to master directly. All changes should be made through a pull request. Yes. Nobody should ever push to master directly. All changes should be
made through a pull request.
### Who assigns maintainers? ### Who assigns maintainers?