Merge approval criteria

This is based on feedback from @rjnagal.

Docker-DCO-1.1-Signed-off-by: Glyn Normington <gnormington@gopivotal.com> (github: glyn)
This commit is contained in:
Glyn Normington 2014-06-13 11:29:39 +01:00
parent f589d42e81
commit 74409a5de5
2 changed files with 6 additions and 6 deletions

View File

@ -107,10 +107,10 @@ or `Fixes #XXX`, which will automatically close the issue when merged.
libcontainer maintainers use LGTM (looks good to me) in comments on the code review libcontainer maintainers use LGTM (looks good to me) in comments on the code review
to indicate acceptance. to indicate acceptance.
A change requires LGTMs from an absolute majority of the maintainers of each A change requires LGTMs from at lease one maintainer of each
component affected. For example, if a change affects docs/ and registry/, it component affected. For example, if a change affects `netlink/` and `security/`, it
needs an absolute majority from the maintainers of docs/ AND, separately, an needs at least one LGTM from the maintainers of `netlink/` AND, separately, at
absolute majority of the maintainers of registry. least one LGTM from the maintainers of `security/`.
For more details see [MAINTAINERS.md](hack/MAINTAINERS.md) For more details see [MAINTAINERS.md](hack/MAINTAINERS.md)

View File

@ -71,10 +71,10 @@ This means that all decisions are made by default by Michael. Since making
every decision himself would be highly un-scalable, in practice decisions every decision himself would be highly un-scalable, in practice decisions
are spread across multiple maintainers. are spread across multiple maintainers.
The relevant maintainers for a pull request can be worked out in 2 steps: The relevant maintainers for a pull request can be worked out in two steps:
* Step 1: Determine the subdirectories affected by the pull request. This * Step 1: Determine the subdirectories affected by the pull request. This
might be `src/registry`, `docs/source/api`, or any other part of the repo. might be `netlink/` and `security/`, or any other part of the repo.
* Step 2: Find the `MAINTAINERS` file which affects this directory. If the * Step 2: Find the `MAINTAINERS` file which affects this directory. If the
directory itself does not have a `MAINTAINERS` file, work your way up directory itself does not have a `MAINTAINERS` file, work your way up