all: change absolute wiki links to relative

Change-Id: I534ed3b8f45a69ff388ba4d081916bc5c77559dd Reviewed-on: https://go-review.googlesource.com/c/wiki/+/595815 Auto-Submit: Ian Lance Taylor <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Commit-Queue: Ian Lance Taylor <[email protected]>
golang · Jun 28, 2024 · 171916a · 171916a
1 parent 6aedc0b
commit 171916a
Show file tree

Hide file tree

Showing 14 changed files with 23 additions and 23 deletions.
diff --git a/AssemblyPolicy.md b/AssemblyPolicy.md
@@ -10,7 +10,7 @@ In general, the rules are:
 * Minimize use of assembly. We'd rather have a small amount of assembly for a 50% speedup rather than twice as much assembly for a 55% speedup. Explain the decision to place the assembly/Go boundary where it is in the commit message, and support it with benchmarks.
 * Use higher level programs to generate non-trivial amounts of assembly, either standalone Go programs or `go get`-able programs, like [avo](https://github.com/mmcloughlin/avo). Output of other reproducible processes (like formally verified code generators) will also be considered. Discuss the implementation strategy on the issue tracker in advance.
 * Use small, testable units (25–75 lines) called from higher-level logic written in Go. If using small, testable functions called from logic written in Go is too slow, use small, testable assembly units with Go-compatible wrappers, so that Go tests can still test the individual units.
-* Any assembly function needs a reference Go implementation, that’s tested side-by-side with the assembly. Follow [golang.org/wiki/TargetSpecific](https://go.dev/wiki/TargetSpecific) for structure and testing practices.
+* Any assembly function needs a reference Go implementation, that’s tested side-by-side with the assembly. Follow [TargetSpecific](/wiki/TargetSpecific) for structure and testing practices.
 * The interface of the assembly units and of the reference Go implementation must be the same across architectures, unless the platforms have fundamentally different capabilities (such as high-level cryptographic instructions).
 * Unless the Go Security team explicitly commits to owning the specific implementation, an external contributor must commit to maintaining it. If changes are required (for example as part of a broader refactor) and the maintainer is not available, the assembly will be removed.
 * The code must be tested in our CI. This means there need to be builders that support the instructions, and if there are multiple (or fallback) paths they must be tested separately. (Tip: use `GODEBUG=cpu.X=off` to disable detection of CPU features.)

diff --git a/CommitMessage.md b/CommitMessage.md
@@ -74,7 +74,7 @@ Notably, the first line subject should **not** contain the `x/crypto/` prefix. W
 ## GitHub Pull Requests
 
 If you're using GitHub Pull Requests, your commit message is constructed by GerritBot based on your
-PR's title & description. See https://go.dev/wiki/GerritBot#how-does-gerritbot-determine-the-final-commit-message.
+PR's title & description. See [How does GerritBot determine the final commit message?](/wiki/GerritBot#how-does-gerritbot-determine-the-final-commit-message)
 
 If somebody asks you to modify your commit message, you'll need to modify your PR.
 

diff --git a/DashboardBuilders.md b/DashboardBuilders.md
@@ -34,7 +34,7 @@ The LUCI system requires builders to run two applications which authenticate to
   1. [Create an issue](https://github.com/golang/go/issues/new?labels=new-builder&title=x%2Fbuild%3A+add+LUCI+%3Cos-arch%3E+builder) on the Go Issue tracker requesting the addition of a new builder and assign it yourself.
      1. The title of the issue should be in the format: `x/build: add LUCI <os-arch> builder`.
      1. Choose a hostname and state its value in the issue body. The hostname should follow the following format: <GOOS>-<GOOARCH>-<GitHub handle of maintainer>. The Go team may ask that it be changed if there is any conflict with the name.
-     1. Add the label "new-builder". (You can post a comment on the issue stating `@gopherbot, please add label new-builder.` in the issue to have [gopherbot](https://go.dev/wiki/gopherbot) add it for you.)
+     1. Add the label "new-builder". (You can post a comment on the issue stating `@gopherbot, please add label new-builder.` in the issue to have [gopherbot](/wiki/gopherbot) add it for you.)
 
   1. Use `golang.org/x/build/cmd/genbotcert` to generate both a certificate signing request (_hostname_.csr) and a TLS private key (_hostname_.key) using the hostname (chosen beforehand) as input. Add a .txt file extension to the certificate signing request (_hostname_.csr.txt) and attach it to the GitHub issue. A team member will attach the resulting certificate (_hostname_.cert) to the GitHub issue.
      1. `genbotcert -bot-hostname <hostname>`
@@ -52,7 +52,7 @@ The LUCI system requires builders to run two applications which authenticate to
 
 ### Security notes
 
-Generally, low-capacity builders only run code that's already been reviewed & submitted (post-submit testing). We only enable pre-submit testing for builders run by the Go team that have a lot of hardware available. However, the [Gomote tool](https://go.dev/wiki/Gomote) is available for a number of people on the Go team and in the Go community that lets them have arbitrary access to the builders for development & debugging.
+Generally, low-capacity builders only run code that's already been reviewed & submitted (post-submit testing). We only enable pre-submit testing for builders run by the Go team that have a lot of hardware available. However, the [Gomote tool](/wiki/Gomote) is available for a number of people on the Go team and in the Go community that lets them have arbitrary access to the builders for development & debugging.
 
 For paranoia reasons, you might want to run your builder in an isolated network that can't access any of your internal resources.
 

diff --git a/Gardening.md b/Gardening.md
@@ -12,7 +12,7 @@ This page lists common Go gardening tasks.
 
 If you've been regularly active in the Go community for some time, feel free to ask for Gerrit and/or GitHub access to modify things.
 
-See https://go.dev/wiki/GerritAccess and https://go.dev/wiki/GitHubAccess
+See [GerritAccess](/wiki/GerritAccess) and [GitHubAccess](/wiki/GitHubAccess).
 
 ## Gardening Tasks
 
@@ -36,7 +36,7 @@ While triaging the bug:
 * does the relevant package [have a primary owner](https://dev.golang.org/owners)? Mention them in a comment. If not, add the `help wanted` label.
 * if the relevant package has no owner, but appears to be complex and deeply technical in nature, add the `ExpertNeeded` label.
 
-When the issue has been triaged, add an appropriate label (per https://go.dev/wiki/HandlingIssues) to mark it as such.
+When the issue has been triaged, add an appropriate label (per [HandlingIssues](/wiki/HandlingIssues)) to mark it as such.
 
 ### WaitingForInfo
 
@@ -60,6 +60,6 @@ If a new CL arrives without a test, but could/should have a test, ask if they co
 
 ### Pending CLs: run TryBots
 
-If you have access (see https://go.dev/wiki/GerritAccess) to run the TryBots and you see a CL with plausible (and non-malicious) code, kick off the TryBots. (We've never seen malicious code trying to escape our TryBot sandboxes, but that's why it's not automatic yet. Please alert us if you see something.)
+If you have access (see [GerritAccess](/wiki/GerritAccess)) to run the TryBots and you see a CL with plausible (and non-malicious) code, kick off the TryBots. (We've never seen malicious code trying to escape our TryBot sandboxes, but that's why it's not automatic yet. Please alert us if you see something.)
 
 
diff --git a/GerritAccess.md b/GerritAccess.md
@@ -4,7 +4,7 @@ title: Gerrit Access
 
 There are two types of Gerrit access described here, with different powers & responsibilities. Only ask for access if you're an active member of the community. New contributors should participate in the Gerrit code review process for some time before requesting access.
 
-(For GitHub access, see https://go.dev/wiki/GitHubAccess)
+(For GitHub access, see [GitHubAccess](/wiki/GitHubAccess))
 
 ## Running TryBots ("may-start-trybots")
 
@@ -13,7 +13,7 @@ TryBots run in a somewhat-secure and somewhat-isolated environment,
 but they're not perfectly security hardened.
 You must skim the CL for anything malicious before starting TryBots.
 
-See [LUCI](https://go.dev/wiki/LUCI#TryBots) for details on triggering TryBots.
+See [LUCI](/wiki/LUCI#TryBots) for details on triggering TryBots.
 
 All approvers (see next section) have TryBot access automatically. Others can request TryBot access. See [Requesting Access](#requesting-access) below.
 
@@ -68,5 +68,5 @@ Decisions about granting access are made by the Go release team at Google. If yo
 
 ## Once you have access
 
-Go help garden! See https://go.dev/wiki/Gardening.
+Go help garden! See [Gardening](/wiki/Gardening).
 
diff --git a/GitHubAccess.md b/GitHubAccess.md
@@ -4,7 +4,7 @@ title: GitHubAccess
 
 There are two types of GitHub access described here, with different powers & responsibilities. Only ask for access if you're an active member of the community. New contributors should participate in the GitHub & Gerrit review process for some time before requesting access.
 
-(For Gerrit access, see https://go.dev/wiki/GerritAccess)
+(For Gerrit access, see [GerritAccess](/wiki/GerritAccess))
 
 ## Assignees
 
@@ -26,5 +26,5 @@ To request any of the access types above, file a new issue (https://go.dev/issue
 
 ## Once you have access
 
-Go help garden! See https://go.dev/wiki/Gardening.
+Go help garden! See [Gardening](/wiki/Gardening).
 
diff --git a/Go-Release-Cycle.md b/Go-Release-Cycle.md
@@ -109,7 +109,7 @@ milestone above).
 
 While the current release is being stabilized, the tree reopens for work on the
 next. During this period, fixes intended for the current release need to be
-[cherry-picked onto the release branch](https://go.dev/wiki/MinorReleases#making-cherry-pick-cls).
+[cherry-picked onto the release branch](/wiki/MinorReleases#making-cherry-pick-cls).
 Unlike cherry-picks for minor releases, these changes don't need a backport
 issue and don't need to be approved by the release team. As long as they're
 permitted by the [freeze policy](#may--november-week-4-release-freeze-begins),
@@ -154,7 +154,7 @@ Minor releases to address problems (including security issues) for Go 1.x stop
 once Go 1.x+2 is released. For more about security updates, see the
 [security policy](https://go.dev/security).
 
-See also the [MinorReleases](https://go.dev/wiki/MinorReleases) wiki page.
+See also the [MinorReleases](/wiki/MinorReleases) wiki page.
 
 ## Freeze Exceptions
 

diff --git a/LUCI.md b/LUCI.md
@@ -27,7 +27,7 @@ on the Gerrit CL page.
 Gerrit page for an example CL.](https://github.com/golang/go/assets/1248668/1a11fa8c-14cd-4b97-968c-6c52a8634c51)
 
 Every TryBot run includes a default set of the most common builders.
-[SlowBots](https://go.dev/wiki/SlowBots) provide additional testing controls.
+[SlowBots](/wiki/SlowBots) provide additional testing controls.
 
 ## Troubleshooting
 

diff --git a/LinuxKernelSignalVectorBug.md b/LinuxKernelSignalVectorBug.md
@@ -260,7 +260,7 @@ The bug is still present, and memory corruption may still occur.
 
 ## Questions?
 
-Ask on the mailing list [email protected], or on any Go forum as described at [Questions](https://go.dev/wiki/Questions).
+Ask on the mailing list [email protected], or on any Go forum as described at [Questions](/wiki/Questions).
 
 ## Details
 

diff --git a/MinimumRequirements.md b/MinimumRequirements.md
@@ -48,7 +48,7 @@ Generally only the latest release version only. We have a builder, but it's not
 
 ### [FreeBSD](FreeBSD)
 
-See https://go.dev/wiki/FreeBSD#go-on-freebsd for supported FreeBSD/Architecture/Go versions matrix.
+See [Go on FreeBSD](/wiki/FreeBSD#go-on-freebsd) for supported FreeBSD/Architecture/Go versions matrix.
 
 ### [NetBSD](NetBSD)
 

diff --git a/PerformanceMonitoring.md b/PerformanceMonitoring.md
@@ -46,7 +46,7 @@ baseline version of source code as the "baseline."
 Do you have a Gerrit change that you want to run against our benchmarks?
 
 Select a builder containing the word `perf` in the "Choose Tryjobs" dialog that
-appears when selecting a [SlowBot](https://go.dev/wiki/SlowBots).
+appears when selecting a [SlowBot](/wiki/SlowBots).
 
 There are two kinds of presubmit builders for performance testing:
 - `perf_vs_parent`, which measures the performance delta of a change in isolation.

diff --git a/PortingPolicy.md b/PortingPolicy.md
@@ -62,7 +62,7 @@ All Linux first class ports are for systems using glibc only.  Linux systems usi
 
 In general, people changing the Go tools and standard library must not break any of the first class ports listed above.  A change that breaks a first class port must be fixed or rolled back.
 
-A change that breaks a secondary port will not necessarily be rolled back.  If there is some reasonable possibility of breaking a secondary port developers are encouraged to make sure that the ports continue to work (for example, by running [port-specific trybots](https://go.dev/wiki/SlowBots)).  Developers are also encouraged to notify secondary port maintainers of any possible port-specific problems, which they can do by reaching out to the appropriate [GitHub team(s)](https://github.com/orgs/golang/teams/port-maintainers/teams).  That said, ultimately the port maintainers are responsible for keeping their ports working.
+A change that breaks a secondary port will not necessarily be rolled back.  If there is some reasonable possibility of breaking a secondary port developers are encouraged to make sure that the ports continue to work (for example, by running [port-specific trybots](/wiki/SlowBots)).  Developers are also encouraged to notify secondary port maintainers of any possible port-specific problems, which they can do by reaching out to the appropriate [GitHub team(s)](https://github.com/orgs/golang/teams/port-maintainers/teams).  That said, ultimately the port maintainers are responsible for keeping their ports working.
 
 ## Broken ports
 

diff --git a/TestFailures.md b/TestFailures.md
@@ -30,7 +30,7 @@ fulfilling its purpose.
 A test failure is typically noticed from:
 * the [Go build dashboard](https://build.golang.org), especially during [builder
   triage](https://go.dev/issue/52653);
-* TryBot or [SlowBot](https://go.dev/wiki/SlowBots) failures on a pending
+* TryBot or [SlowBot](/wiki/SlowBots) failures on a pending
   change;
 * running `go test` on a specific package or packages, either working within a
   Go project repository or as part of (say) `go test all` in a user's own
@@ -105,7 +105,7 @@ subteam(s) of
 on the issue.
 
 If the failure appears to affect at least one
-[first class port](https://go.dev/wiki/PortingPolicy#first-class-ports),
+[first class port](/wiki/PortingPolicy#first-class-ports),
 add the issue to the current release milestone and label it
 [`release-blocker`](https://github.com/golang/go/labels/release-blocker).
 Otherwise, add the issue to the `Backlog` milestone.
@@ -181,7 +181,7 @@ to add an issue in the `KnownIssue` field; note that builders with known issues
 will generally be skipped during dashboard triage.
 
 A broken builder for a
-[first class port](https://go.dev/wiki/PortingPolicy#first-class-ports)
+[first class port](/wiki/PortingPolicy#first-class-ports)
 should have its known issue(s) labeled `release-blocker`, pending a decision
 to either fix the builder or drop support for the affected version of the
 platform.

diff --git a/gopherbot.md b/gopherbot.md
@@ -34,7 +34,7 @@ As always, patches are welcome!
 
 ## Backporting issues
 
-gopherbot is capable of opening backport issues according to [MinorReleases](https://go.dev/wiki/MinorReleases) in response to comments like the following on the main issue.
+gopherbot is capable of opening backport issues according to [MinorReleases](/wiki/MinorReleases) in response to comments like the following on the main issue.
 
 > @gopherbot please consider this for backport to 1.10, it's a regression.