Merge pull request #12306 from goltermann/oncall

Add post v1.0 PR merge details
This commit is contained in:
Dawn Chen 2015-08-05 15:27:19 -07:00
commit b9c118ada6
2 changed files with 10 additions and 8 deletions

View File

@ -98,6 +98,7 @@ git push -f origin myfeature
1. Visit http://github.com/$YOUR_GITHUB_USERNAME/kubernetes
2. Click the "Compare and pull request" button next to your "myfeature" branch.
3. Check out the pull request [process](pull-requests.md) for more details
### When to retain commits and when to squash

View File

@ -47,18 +47,19 @@ We want to limit the total number of PRs in flight to:
* Remove old PRs that would be difficult to rebase as the underlying code has changed over time
* Encourage code velocity
RC to v1.0 Pull Requests
------------------------
Life of a Pull Request
----------------------
Between the first RC build (~6/22) and v1.0, we will adopt a higher bar for PR merges. For v1.0 to be a stable release, we need to ensure that any fixes going in are very well tested and have a low risk of breaking anything. Refactors and complex changes will be rejected in favor of more strategic and smaller workarounds.
Unless in the last few weeks of a milestone when we need to reduce churn and stabilize, we aim to be always accepting pull requests.
These PRs require:
* A risk assessment by the code author in the PR. This should outline which parts of the code are being touched, the risk of regression, and complexity of the code.
* Two LGTMs from experienced reviewers.
Either the [on call](https://github.com/GoogleCloudPlatform/kubernetes/wiki/Kubernetes-on-call-rotation) manually or the [submit queue](../../contrib/submit-queue/) automatically will manage merging PRs.
Once those requirements are met, they will be labeled [ok-to-merge](https://github.com/GoogleCloudPlatform/kubernetes/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+label%3Aok-to-merge) and can be merged.
There are several requirements for the submit queue to work:
* Author must have signed CLA ("cla: yes" label added to PR)
* No changes can be made since last lgtm label was applied
* k8s-bot must have reported the GCE E2E build and test steps passed (Travis, Shippable and Jenkins build)
These restrictions will be relaxed after v1.0 is released.
Additionally, for infrequent or new contributors, we require the on call to apply the "ok-to-merge" label manually. This is gated by the [whitelist](../../contrib/submit-queue/whitelist.txt).
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->