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 <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
diff --git a/AssemblyPolicy.md b/AssemblyPolicy.md
index 2f48292..7f9554d 100644
--- a/AssemblyPolicy.md
+++ b/AssemblyPolicy.md
@@ -10,7 +10,7 @@
* 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
index efef649..3b1630a 100644
--- a/CommitMessage.md
+++ b/CommitMessage.md
@@ -74,7 +74,7 @@
## 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
index fb50dbb..402cf2f 100644
--- a/DashboardBuilders.md
+++ b/DashboardBuilders.md
@@ -34,7 +34,7 @@
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 @@
### 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
index 250bdc0..7553563 100644
--- a/Gardening.md
+++ b/Gardening.md
@@ -12,7 +12,7 @@
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 @@
* 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 @@
### 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
index 234695c..0b77c68 100644
--- a/GerritAccess.md
+++ b/GerritAccess.md
@@ -4,7 +4,7 @@
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 @@
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 @@
## 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
index 064d809..14bbba9 100644
--- a/GitHubAccess.md
+++ b/GitHubAccess.md
@@ -4,7 +4,7 @@
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 @@
## 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
index fa44629..6487a17 100644
--- a/Go-Release-Cycle.md
+++ b/Go-Release-Cycle.md
@@ -109,7 +109,7 @@
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 @@
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
index 501731a..7867522 100644
--- a/LUCI.md
+++ b/LUCI.md
@@ -27,7 +27,7 @@
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
index d7fb7bf..73064d4 100644
--- a/LinuxKernelSignalVectorBug.md
+++ b/LinuxKernelSignalVectorBug.md
@@ -260,7 +260,7 @@
## Questions?
-Ask on the mailing list golang-nuts@googlegroups.com, or on any Go forum as described at [Questions](https://go.dev/wiki/Questions).
+Ask on the mailing list golang-nuts@googlegroups.com, or on any Go forum as described at [Questions](/wiki/Questions).
## Details
diff --git a/MinimumRequirements.md b/MinimumRequirements.md
index b71dbe2..f613dca 100644
--- a/MinimumRequirements.md
+++ b/MinimumRequirements.md
@@ -48,7 +48,7 @@
### [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
index 442a34a..22ed098 100644
--- a/PerformanceMonitoring.md
+++ b/PerformanceMonitoring.md
@@ -46,7 +46,7 @@
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
index 00af9a8..9b07f32 100644
--- a/PortingPolicy.md
+++ b/PortingPolicy.md
@@ -62,7 +62,7 @@
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
index 7c42e72..8910f47 100644
--- a/TestFailures.md
+++ b/TestFailures.md
@@ -30,7 +30,7 @@
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 @@
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 @@
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
index 9d86740..0aa8344 100644
--- a/gopherbot.md
+++ b/gopherbot.md
@@ -34,7 +34,7 @@
## 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.
