mirror of
https://github.com/k3s-io/kubernetes.git
synced 2025-07-23 11:50:44 +00:00
Merge pull request #12306 from goltermann/oncall
Add post v1.0 PR merge details
This commit is contained in:
commit
b9c118ada6
@ -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
|
||||
|
||||
|
@ -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 -->
|
||||
|
Loading…
Reference in New Issue
Block a user