An overview of how pull requests are managed for kubernetes. This document assumes the reader has already followed the development guide to set up their environment.
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.
Either the on call manually or the github "munger" submit-queue plugin automatically will manage merging PRs.
There are several requirements for the submit-queue to work:
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.
The following will save time for both you and your reviewer:
hack/verify-all.sh
passes.hack/test-go.sh
passes.hack/test-integration.sh
passes.This section applies only to pull requests on the master branch. For cherry-pick PRs, see the Cherrypick instructions
release-note-label-needed
label.release-note-label-needed
label must be removed and one of the other release-note-*
labels must be added.release-note-none
is a valid option if the PR does not need to be mentioned
at release time.release-note
labeled PRs generate a release note using the PR title by
default OR the release-note block in the PR template if filled in.The only exception to these rules is when a PR is not a cherry-pick and is
targeted directly to the non-master branch. In this case, a release-note-*
label is required for that non-master PR.
NOTE: THIS TOOLING IS NOT YET AVAILABLE, BUT COMING SOON!
At any time, you can see what the release notes will look like on any branch.
$ git pull https://github.com/kubernetes/release
$ RELNOTES=$PWD/release/relnotes
$ cd /to/your/kubernetes/repo
$ $RELNOTES -man # for details on how to use the tool
# Show release notes from the last release on a branch to HEAD
$ $RELNOTES --raw --branch=master
Pull requests that are purely support questions will be closed and redirected to stackoverflow. We do this to consolidate help/support questions into a single channel, improve efficiency in responding to requests and make FAQs easier to find.
Pull requests older than 2 weeks will be closed. Exceptions can be made for PRs that have active review comments, or that are awaiting other dependent PRs. Closed pull requests are easy to recreate, and little work is lost by closing a pull request that subsequently needs to be reopened. We want to limit the total number of PRs in flight to:
We use a variety of automation to manage pull requests. This automation is described in detail elsewhere.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。