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
|
||||
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)
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue