diff options
Diffstat (limited to 'project')
| -rw-r--r-- | project/ISSUE-TRIAGE.md | 1 | ||||
| -rw-r--r-- | project/RELEASE-CHECKLIST.md | 8 | ||||
| -rw-r--r-- | project/REVIEWING.md | 28 |
3 files changed, 32 insertions, 5 deletions
diff --git a/project/ISSUE-TRIAGE.md b/project/ISSUE-TRIAGE.md index ac1ea26ba2..35bacdb314 100644 --- a/project/ISSUE-TRIAGE.md +++ b/project/ISSUE-TRIAGE.md @@ -52,6 +52,7 @@ have: |---------------------------| | area/api | | area/builder | +| area/bundles | | area/cli | | area/daemon | | area/distribution | diff --git a/project/RELEASE-CHECKLIST.md b/project/RELEASE-CHECKLIST.md index 8a0be63811..d6f6aaa2ef 100644 --- a/project/RELEASE-CHECKLIST.md +++ b/project/RELEASE-CHECKLIST.md @@ -71,8 +71,8 @@ We cherry-pick only the commits we want into the bump branch: # get the commits ids we want to cherry-pick git log # cherry-pick the commits starting from the oldest one, without including merge commits -git cherry-pick <commit-id> -git cherry-pick <commit-id> +git cherry-pick -s -x <commit-id> +git cherry-pick -s -x <commit-id> ... ``` @@ -346,7 +346,7 @@ Each time you'll want to produce a new release candidate, you will start by adding commits to the branch, usually by cherry-picking from master: ```bash -git cherry-pick -x -m0 <commit_id> +git cherry-pick -s -x -m0 <commit_id> ``` You want your "bump commit" (the one that updates the CHANGELOG and VERSION @@ -500,7 +500,7 @@ and you can check its progress with the CDN Cloudfront Chrome addon. git checkout master git fetch git reset --hard origin/master -git cherry-pick $VERSION +git cherry-pick -s -x $VERSION git push $GITHUBUSER merge_release_$VERSION echo "https://github.com/$GITHUBUSER/docker/compare/docker:master...$GITHUBUSER:merge_release_$VERSION?expand=1" ``` diff --git a/project/REVIEWING.md b/project/REVIEWING.md index be6c2ba6ae..4d99dbd1d6 100644 --- a/project/REVIEWING.md +++ b/project/REVIEWING.md @@ -128,11 +128,37 @@ completeness, validity, and breadth of coverage across all existing and new docu They should ask for any editorial change that makes the documentation more consistent and easier to understand. +The docker/docker repository only contains _reference documentation_, all +"narrative" documentation is kept in a [unified documentation +repository](https://github.com/docker/docker.github.io). Reviewers must +therefore verify which parts of the documentation need to be updated. Any +contribution that may require changing the narrative should get the +`impact/documentation` label: this is the signal for documentation maintainers +that a change will likely need to happen on the unified documentation +repository. When in doubt, it’s better to add the label and leave it to +documentation maintainers to decide whether it’s ok to skip. In all cases, +leave a comment to explain what documentation changes you think might be needed. + +- If the pull request does not impact the documentation at all, the docs review + step is skipped, and the pull request is ready to merge. +- If the changes in + the pull request require changes to the reference documentation (either + command-line reference, or API reference), those changes must be included as + part of the pull request and will be reviewed now. Keep in mind that the + narrative documentation may contain output examples of commands, so may need + to be updated as well, in which case the `impact/documentation` label must + be applied. +- If the PR has the `impact/documentation` label, merging is delayed until a + documentation maintainer acknowledges that a corresponding documentation PR + (or issue) is opened on the documentation repository. Once a documentation + maintainer acknowledges the change, she/he will move the PR to `status/4-merge` + for a code maintainer to push the green button. + Changes and additions to docs must be reviewed and approved (LGTM'd) by a minimum of two docs sub-project maintainers. If the docs change originates with a docs maintainer, only one additional LGTM is required (since we assume a docs maintainer approves of their own PR). -Once documentation is approved (see below), a maintainer should make sure to remove this label and +Once documentation is approved, a maintainer should make sure to remove this label and add the next one. Possible transitions from this state: |