diff options
Diffstat (limited to 'project')
| -rw-r--r-- | project/ARM.md | 15 | ||||
| -rw-r--r-- | project/ISSUE-TRIAGE.md | 11 | ||||
| -rw-r--r-- | project/PATCH-RELEASES.md | 15 |
3 files changed, 35 insertions, 6 deletions
diff --git a/project/ARM.md b/project/ARM.md index dc44e95aa8..c4d21bf27a 100644 --- a/project/ARM.md +++ b/project/ARM.md @@ -28,3 +28,18 @@ So for example in order to build a Docker binary one has to 1. clone the Docker/Docker repository on an ARM device `git clone git@github.com:docker/docker.git` 2. change into the checked out repository with `cd docker` 3. execute `make binary` to create a Docker Engine binary for ARM + +## Kernel modules +A few libnetwork integration tests require that the kernel be +configured with "dummy" network interface and has the module +loaded. However, the dummy module may be not loaded automatically. + +To load the kernel module permanently, run these commands as `root`. + + modprobe dummy + echo "dummy" >> /etc/modules + +On some systems you also have to sync your kernel modules. + + oc-sync-kernel-modules + depmod diff --git a/project/ISSUE-TRIAGE.md b/project/ISSUE-TRIAGE.md index 5220382a74..57c441bf36 100644 --- a/project/ISSUE-TRIAGE.md +++ b/project/ISSUE-TRIAGE.md @@ -1,10 +1,10 @@ Triaging of issues ------------------ -Triage provides an important way to contribute to an open source project. Triage helps ensure issues resolve quickly by: +Triage provides an important way to contribute to an open source project. Triage helps ensure issues resolve quickly by: -- Describing the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for an issue to explain how an end user experiences an problem and what actions they took. -- Giving a contributor the information they need before they commit to resolving an issue. +- Describing the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for an issue to explain how an end user experiences a problem and what actions they took. +- Giving a contributor the information they need before they commit to resolving an issue. - Lowering the issue count by preventing duplicate issues. - Streamlining the development process by preventing duplicate discussions. @@ -19,9 +19,9 @@ Before triaging an issue very far, make sure that the issue's author provided th - the output of `uname -a` - a reproducible case if this is a bug, Dockerfiles FTW - host distribution and version ( ubuntu 14.04, RHEL, fedora 23 ) -- page URL if this is a docs issue or the name of a man page +- page URL if this is a docs issue or the name of a man page -Depending on the issue, you might not feel all this information is needed. Use your best judgement. If you cannot triage an issue using what its author provided, explain kindly to the author that they must provide the above information to clarify the problem. +Depending on the issue, you might not feel all this information is needed. Use your best judgement. If you cannot triage an issue using what its author provided, explain kindly to the author that they must provide the above information to clarify the problem. If the author provides the standard information but you are still unable to triage the issue, request additional information. Do this kindly and politely because you are asking for more of the author's time. @@ -89,4 +89,3 @@ urgent). | priority/P3 | Best effort: those are nice to have / minor issues. | And that's it. That should be all the information required for a new or existing contributor to come in an resolve an issue. - diff --git a/project/PATCH-RELEASES.md b/project/PATCH-RELEASES.md index 76a93e6505..548db9ab4d 100644 --- a/project/PATCH-RELEASES.md +++ b/project/PATCH-RELEASES.md @@ -51,3 +51,18 @@ review sessions take place on a weekly basis, more frequent if needed: > a different procedure. Security releases are developed in a private > repository, released and tested under embargo before they become > publicly available. + +## Deciding on the content of a patch release + +When the criteria for moving forward with a patch release are met, the release +manager will decide on the exact content of the release. + +- Fixes to all P0 issues *must* be included in the release. +- Fixes to *some* P1, P2, and P3 issues *may* be included as part of the patch + release depending on the severity of the issue and the risk associated with + the patch. + +Any code delivered as part of a patch release should make life easier for a +significant amount of users with zero chance of degrading anybody's experience. +A good rule of thumb for that is to limit cherry-picking to small patches, which +fix well-understood issues, and which come with verifiable tests. |