devel/sig-release: Initial link cleanup

Signed-off-by: Stephen Augustus <[email protected]>

Author: justaugustus

contributors/devel/sig-release/cherry-picks.md

@@ -19,7 +19,7 @@ branches.
    considered implicit for all code within cherry-pick pull requests,
    **unless there is a large conflict**.
 - A pull request merged against the master branch.
-- [Release branch](https://git.k8s.io/release/docs/branching.md) exists.
+- The release branch exists (example: [`release-1.18`](https://github.com/kubernetes/kubernetes/tree/release-1.18))
 - The normal git and GitHub configured shell environment for pushing to your
    kubernetes `origin` fork on GitHub and making a pull request against a
    configured remote `upstream` that tracks
@@ -71,22 +71,26 @@ continue, bolster your case by supplementing your PR with e.g.,
 ## Initiate a Cherry-pick
 
 - Run the [cherry-pick script](https://git.k8s.io/kubernetes/hack/cherry_pick_pull.sh)
+
   This example applies a master branch PR #98765 to the remote branch
-  `upstream/release-3.14`: `hack/cherry_pick_pull.sh upstream/release-3.14
-  98765`
+  `upstream/release-3.14`:
+
+  ```shell
+  hack/cherry_pick_pull.sh upstream/release-3.14 98765
+  ```
 
   - Be aware the cherry-pick script assumes you have a git remote called
     `upstream` that points at the Kubernetes github org.
 
-    Please see our [recommended Git workflow](https://git.k8s.io/community/contributors/guide/github-workflow.md#workflow).
+    Please see our [recommended Git workflow](/contributors/guide/github-workflow.md#workflow).
 
   - You will need to run the cherry-pick script separately for each patch
     release you want to cherry-pick to.
 
 - Your cherry-pick PR will immediately get the
   `do-not-merge/cherry-pick-not-approved` label.
 
-  [Normal rules apply for code merge](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md#tldr),
+  [Normal rules apply for code merge](/contributors/devel/sig-release/release.md#tldr),
   with some additional caveats outlined in the next section of this document.
 
 ## Cherry-pick Review
@@ -99,7 +103,7 @@ except the release note stanza will auto-populate from the master
 branch pull request from which the cherry-pick originated.  If this
 is unsuccessful the `do-not-merge/release-note-label-needed` label
 will be applied and the cherry-pick author must edit the pull request
-description to [add a release note](https://git.k8s.io/community/contributors/guide/release-notes.md)
+description to [add a release note](/contributors/guide/release-notes.md)
 or include in a comment the `/release-note-none` command.
 
 Cherry-pick pull requests are reviewed slightly differently than normal
@@ -114,15 +118,12 @@ pull requests on the master branch in that they:
 - Have one additional level of review in that they must be approved
   specifically for cherry-pick by branch approvers.
 
-  The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
-  will triage PRs targeted to the next .0 minor release branch up until the
-  release, while the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
-  will handle all cherry-picks to patch releases.
+  The [Release Managers][release-managers] are the final approvers on release
+  branches.
 
-  The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
-  or the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
-  are the final authority on branch approval by removing the
-  `do-not-merge/cherry-pick-not-approved` label and triggering a merge into the
+  Approval is signified by a Release Manager manually applying the
+  `cherry-pick-approved` label. This action removes the
+  `do-not-merge/cherry-pick-not-approved` label and triggers a merge into the
   target branch.
 
   The team scrubs through incoming cherry-picks on at least a weekly basis,
@@ -150,9 +151,10 @@ pull requests on the master branch in that they:
 
 ## Searching for Cherry-picks
 
-- [A sample search on kubernetes/kubernetes pull requests that are labeled as `cherry-pick-approved`](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Acherry-pick-approved)
+Examples (based on cherry picks targeting the `release-1.18` branch):
 
-- [A sample search on kubernetes/kubernetes pull requests that are labeled as `do-not-merge/cherry-pick-not-approved`](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Ado-not-merge%2Fcherry-pick-not-approved)
+- [`cherry-pick-approved`](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Acherry-pick-approved+base%3Arelease-1.18)
+- [`do-not-merge/cherry-pick-not-approved`](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Ado-not-merge%2Fcherry-pick-not-approved+base%3Arelease-1.18)
 
 ## Troubleshooting Cherry-picks
 
@@ -177,7 +179,7 @@ longer supported.
 As discussed in a sig-release meeting on 2019-01-15, a fix was backported to
 the non supported version.
 
-Reference PR: [#72860](https://github.com/kubernetes/kubernetes/pull/72860#issuecomment-454072746)
+Reference PR: [#72860](https://github.com/kubernetes/kubernetes/pull/72860)
 
 The specific criteria driving the decision was:
 
@@ -193,3 +195,5 @@ A note about the specific case in [#72860](https://github.com/kubernetes/kuberne
 - The patch was exceedingly tiny and very unlikely to introduce new problems
 - Luckily, it was caught shortly after the release was supposed to be
   unsupported
+
+[release-managers]: https://git.k8s.io/sig-release/release-managers.md

contributors/devel/sig-release/getting-builds.md

@@ -1,6 +1,6 @@
 # Getting Kubernetes Builds
 
-You can use [hack/get-build.sh](http://releases.k8s.io/HEAD/hack/get-build.sh)
+You can use [hack/get-build.sh](https://git.k8s.io/kubernetes/hack/get-build.sh)
 to get a build or to use as a reference on how to get the most recent builds
 with curl. With `get-build.sh` you can grab the most recent stable build, the
 most recent release candidate, or the most recent build to pass our ci and gce

contributors/devel/sig-release/release.md

@@ -66,14 +66,13 @@ Return to 'Normal Dev' phase requirements:
 - /lgtm
 - /approved
 
-Merges into the 1.y branch are now [via cherrypicks](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md),
+Merges into the 1.y branch are now [via cherry picks](/contributors/devel/sig-release/cherry-picks.md),
 approved by release branch manager.
 
 In the past there was a requirement for a milestone targeted pull request to
 have an associated GitHub issue opened, but this is no longer the case.
-Features are effectively GitHub issues or [KEPs](https://git.k8s.io/community/keps)
-which lead to subsequent PRs. The general labeling process should be consistent
-across artifact types.
+Features are effectively GitHub issues or [KEPs][keps] which lead to subsequent
+PRs. The general labeling process should be consistent across artifact types.
 
 ---
 
@@ -101,9 +100,9 @@ across artifact types.
   The process of removing an Enhancement from a release milestone if it is not
   fully implemented or is otherwise considered not stable.
 - *release milestone*: semantic version string or
-  [GitHub milestone](https://help.github.com/articles/associating-milestones-with-issues-and-pull-requests/)
+  [GitHub milestone](https://help.github.com/en/github/managing-your-work-on-github/associating-milestones-with-issues-and-pull-requests)
   referring to a release MAJOR.MINOR vX.Y version. See also
-  [release versioning](http://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
+  [release versioning](/contributors/design-proposals/release/versioning.md)
 - *release branch*: Git branch "release-X.Y" created for the vX.Y milestone.
   Created at the time of the vX.Y-beta.0 release and maintained after the
   release for approximately 9 months with vX.Y.Z patch releases.
@@ -172,10 +171,7 @@ general development and work begins there for the next release milestone. Any
 remaining modifications for the current release are cherry picked from master
 back to the release branch. The release is built from the release branch.
 
-Following release, the [Release Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager/README.md)
-cherry picks additional critical fixes from the master branch for a period of
-around 9 months, leaving an overlap of three release versions forward support.
-Thus, each release is part of a broader Kubernetes lifecycle:
+Each release is part of a broader Kubernetes lifecycle:
 
 ![Image of Kubernetes release lifecycle spanning three releases](release-lifecycle.png)
 
@@ -212,32 +208,31 @@ will be made by the release team through the following channels:
   the issue type
 - Emailing the SIG mailing list
   - bootstrapped with group email addresses from the
-    [community sig list](/sig-list.md)
+    [community sig list][sig-list]
   - optionally also directly addressing SIG leadership or other SIG members
 - Messaging the SIG's Slack channel
   - bootstrapped with the slackchannel and SIG leadership from the
-    [community sig list](/sig-list.md)
+    [community sig list][sig-list]
   - optionally directly "@" mentioning SIG leadership or others by handle
 
 ## Adding An Item To The Milestone
 
 ### Milestone Maintainers
 
-The members of the GitHub
-[“kubernetes-milestone-maintainers” team](https://github.com/orgs/kubernetes/teams/kubernetes-milestone-maintainers/members)
-are entrusted with the responsibility of specifying the release milestone on
-GitHub artifacts. This group is [maintained by
-SIG Release](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)
-and has representation from the various SIGs' leadership.
+The members of the [`milestone-maintainers`](https://github.com/orgs/kubernetes/teams/milestone-maintainers/members)
+GitHub team are entrusted with the responsibility of specifying the release
+milestone on GitHub artifacts.
+
+This group is [maintained](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)
+by SIG Release and has representation from the various SIGs' leadership.
 
 ### Feature additions
 
 Feature planning and definition takes many forms today, but a typical example
-might be a large piece of work described in a
-[KEP](https://git.k8s.io/community/keps), with associated task issues in
-GitHub. When the plan has reached an implementable state and work is underway,
-the feature or parts thereof are targeted for an upcoming milestone by creating
-GitHub issues and marking them with the Prow "/milestone" command.
+might be a large piece of work described in a [KEP][keps], with associated task
+issues in GitHub. When the plan has reached an implementable state and work is
+underway, the feature or parts thereof are targeted for an upcoming milestone
+by creating GitHub issues and marking them with the Prow "/milestone" command.
 
 For the first ~4 weeks into the release cycle, the release team's Enhancements
 Lead will interact with SIGs and feature owners via GitHub, Slack, and SIG
@@ -327,3 +322,6 @@ issue kind labels must be set:
 - `kind/failing-test`: CI test case is failing consistently.
 - `kind/feature`: New functionality.
 - `kind/flake`: CI test case is showing intermittent failures.
+
+[keps]: https://git.k8s.io/enhancements/keps
+[sig-list]: /sig-list.md