kotovalexarian-likes-github
/
moby--moby
mirror of https://github.com/moby/moby.git
1
0
Fork 0
Code Releases Activity

modernise the MAINTAINER process documentation to line up with what I understand it to be 

Docker-DCO-1.1-Signed-off-by: Sven Dowideit <SvenDowideit@fosiki.com> (github: SvenDowideit)
This commit is contained in:
Sven Dowideit 2014-04-29 14:52:01 +10:00
parent 6c4e5ee826
commit 48dbee0824
2 changed files with 23 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
hack/MAINTAINERS.md
View File

@ -53,14 +53,17 @@ All decisions affecting docker, big and small, follow the same 3 steps:
* Step 2: Discuss the pull request. Anyone can do this.
* Step 3: Accept or refuse a pull request. The relevant maintainer does this (see below "Who decides what?")
* Step 3: Accept (`LGTM`) or refuse a pull request. The relevant maintainers do
this (see below "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. But how do we
identify the relevant maintainer for a given pull request?
All decisions are pull requests, and the relevant maintainers make
decisions by accepting or refusing the pull request. Review and acceptance
by anyone is denoted by adding a comment in the pull request: `LGTM`.
However, only currently listed `MAINTAINERS` are counted towards the required
majority.
Docker follows the timeless, highly efficient and totally unfair system
known as [Benevolent dictator for
@ -70,19 +73,22 @@ 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 maintainers for a pull request can be worked out in 2 steps:
* Step 1: Determine the subdirectory 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.
* 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.
There is also a `hacks/getmaintainers.sh` script that will print out the
maintainers for a specified directory.
### I'm a maintainer, and I'm going on holiday
Please let your co-maintainers and other contributors know by raising a pull
request that comments out your `MAINTAINERS` file entry using a `#`.
### I'm a maintainer, should I make pull requests too?
@ -91,7 +97,7 @@ made through a pull request.
### Who assigns maintainers?
Solomon.
Solomon has final `LGTM` approval for all pull requests to `MAINTAINERS` files.
### How is this process changed?

10
hack/getmaintainer.sh
View File

@ -1,4 +1,5 @@
#!/bin/sh
#!/usr/bin/env bash
set -e
if [ $# -ne 1 ]; then
echo >&2 "Usage: $0 PATH"
@ -34,6 +35,7 @@ while true; do
fi
done;
} < MAINTAINERS
break
fi
if [ -d .git ]; then
break
@ -46,13 +48,15 @@ done
PRIMARY="${MAINTAINERS[0]}"
PRIMARY_FIRSTNAME=$(echo $PRIMARY | cut -d' ' -f1)
LGTM_COUNT=${#MAINTAINERS[@]}
LGTM_COUNT=$((LGTM_COUNT%2 +1))
firstname() {
echo $1 | cut -d' ' -f1
}
echo "--- $PRIMARY is the PRIMARY MAINTAINER of $1. Assign pull requests to him."
echo "$(firstname $PRIMARY) may assign pull requests to the following secondary maintainers:"
echo "A pull request in $1 will need $LGTM_COUNT LGTM's to be merged."
echo "--- $PRIMARY is the PRIMARY MAINTAINER of $1."
for SECONDARY in "${MAINTAINERS[@]:1}"; do
echo "--- $SECONDARY"
done