diff options
| -rw-r--r-- | development.md | 1 | ||||
| -rw-r--r-- | pull-requests.md | 17 |
2 files changed, 10 insertions, 8 deletions
diff --git a/development.md b/development.md index 87b4b5d0..7fcd6a89 100644 --- a/development.md +++ b/development.md @@ -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 diff --git a/pull-requests.md b/pull-requests.md index e42faa51..6d2eb597 100644 --- a/pull-requests.md +++ b/pull-requests.md @@ -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 --> |