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
to indicate acceptance.
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
needs an absolute majority from the maintainers of docs/ AND, separately, an
absolute majority of the maintainers of registry.
A change requires LGTMs from at lease one maintainer of each
component affected. For example, if a change affects `netlink/` and `security/`, it
needs at least one LGTM from the maintainers of `netlink/` AND, separately, at
least one LGTM from the maintainers of `security/`.
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
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
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
directory itself does not have a `MAINTAINERS` file, work your way up