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:
parent
f589d42e81
commit
74409a5de5
|
@ -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)
|
||||||
|
|
||||||
|
|
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue