From e7c314d78357d551d5d8076e607725f085ab1848 Mon Sep 17 00:00:00 2001 From: AJ Schmidt Date: Fri, 5 Jan 2024 17:51:27 +0000 Subject: [PATCH] replace Jekyll `link` w/ Hugo `relref` --- content/docs/contributing/_index.md | 12 +++++------ content/docs/contributing/code.md | 16 +++++++-------- content/docs/contributing/issues.md | 8 ++++---- content/docs/contributing/prs.md | 10 +++++----- content/docs/maintainers/_index.md | 22 ++++++++++----------- content/docs/maintainers/burn-down-guide.md | 2 +- content/docs/maintainers/forward-merger.md | 6 +++--- content/docs/maintainers/git.md | 10 +++++----- content/docs/maintainers/github-actions.md | 2 +- content/docs/maintainers/style.md | 2 +- content/docs/maintainers/testing.md | 4 ++-- content/docs/releases/hotfix.md | 6 +++--- content/docs/releases/planning.md | 8 ++++---- content/docs/releases/process.md | 12 +++++------ content/docs/releases/schedule.md | 12 +++++------ content/docs/releases/triage.md | 8 ++++---- content/notices/notices.md | 2 +- content/notices/rgn0003.md | 2 +- content/notices/rgn0006.md | 2 +- content/notices/rgn0008.md | 2 +- content/notices/rgn0009.md | 2 +- 21 files changed, 75 insertions(+), 75 deletions(-) diff --git a/content/docs/contributing/_index.md b/content/docs/contributing/_index.md index 355fa70f..b495bb76 100644 --- a/content/docs/contributing/_index.md +++ b/content/docs/contributing/_index.md @@ -1,6 +1,6 @@ --- title: Contributing -linkTitle: Contributing +linkTitle: Contributing description: Gateway to the RAPIDS documentation content type: docs weight: 10 @@ -13,7 +13,7 @@ RAPIDS can only grow with community support and it is vital to include developer ## Getting started -Welcome! We are excited you are here! Before you begin, we ask that everyone review the [Code of Conduct]({% link resources/conduct.md %}) before contributing. +Welcome! We are excited you are here! Before you begin, we ask that everyone review the [Code of Conduct]({{< relref "../maintainers/conduct.md" >}}) before contributing. ### Your first issue @@ -22,7 +22,7 @@ Welcome! We are excited you are here! Before you begin, we ask that everyone rev 3. Comment on the issue saying you are going to work on it 4. Code! Make sure to update unit tests! 5. All RAPIDS projects are released under the Apache-2.0 license, so also make sure all source files that support comments include a copyright and the Apache-2.0 license text. -6. When done, [create your pull request]({% link contributing/prs.md %}) +6. When done, [create your pull request]({{< relref "prs.md" >}}) 7. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed 8. Wait for other developers to review your code and update code as needed 9. Once reviewed and approved, a RAPIDS developer will merge your pull request @@ -33,12 +33,12 @@ Remember, if you are unsure about anything, don't hesitate to comment on issues Once you have gotten your feet wet and are more comfortable with the code, follow these steps to find prioritized issues. -All RAPIDS projects have project boards for triaging [issues]({% link releases/triage.md %}) and planning [features]({% link releases/planning.md %}). +All RAPIDS projects have project boards for triaging [issues]({{< relref "../releases/triage.md" >}}) and planning [features]({{< relref "../releases/planning.md" >}}). ### More details -Review the [Code Contributions]({% link contributing/code.md %}) page. +Review the [Code Contributions]({{< relref "code.md" >}}) page. ## Issues or feedback -File an issue [here](https://github.com/rapidsai/docs/issues/new) for any unexpected problems encountered or general feedback with any of the information on this site. \ No newline at end of file +File an issue [here](https://github.com/rapidsai/docs/issues/new) for any unexpected problems encountered or general feedback with any of the information on this site. diff --git a/content/docs/contributing/code.md b/content/docs/contributing/code.md index c245e1ed..5ded4651 100644 --- a/content/docs/contributing/code.md +++ b/content/docs/contributing/code.md @@ -11,14 +11,14 @@ weight: 10 Outlines the best way for developers and the community to contribute to RAPIDS projects. Contributions can be made in three ways: -- [File a bug report]({% link contributing/issues.md %}) -- [Suggest a new feature or improvement]({% link contributing/issues.md %}) +- [File a bug report]({{< relref "issues.md" >}}) +- [Suggest a new feature or improvement]({{< relref "issues.md" >}}) - [Implement code for an issue](#your-first-issue) ### See also -- [Issues]({% link contributing/issues.md %}) -- [Pull Requests]({% link contributing/prs.md %}) +- [Issues]({{< relref "issues.md" >}}) +- [Pull Requests]({{< relref "prs.md" >}}) ## New developers @@ -31,7 +31,7 @@ If you are new to RAPIDS, make sure to check out to help un 3. Comment on the issue saying you are going to work on it 4. Code! Make sure to update unit tests! 5. All RAPIDS projects are released under the Apache-2.0 license, so also make sure all source files that support comments include a copyright and the Apache-2.0 license text. -6. When done, [create your pull request]({% link contributing/prs.md %}) +6. When done, [create your pull request]({{< relref "prs.md" >}}) 7. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed 8. Wait for other developers to review your code and update code as needed 9. Once reviewed and approved, a RAPIDS developer will merge your pull request @@ -42,7 +42,7 @@ Remember, if you are unsure about anything, don't hesitate to comment on issues Once you have gotten your feet wet and are more comfortable with the code, follow these steps to find prioritized issues. -All RAPIDS projects have project boards for triaging [issues]({% link releases/triage.md %}) and planning [features]({% link releases/planning.md %}). +All RAPIDS projects have project boards for triaging [issues]({{< relref "../releases/triage.md" >}}) and planning [features]({{< relref "../releases/planning.md" >}}). ### What do I work on? @@ -56,7 +56,7 @@ For all others: 3. Select the highest priority issue that you are comfortable working on 4. If you are in the RAPIDS org, assign the issue to yourself. If not, comment on the issue saying you are going to work on it 5. Code! Make sure to update unit tests! -6. When done, [create your pull request]({% link contributing/prs.md %}) +6. When done, [create your pull request]({{< relref "prs.md" >}}) 7. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed 8. Wait for other developers to review your code and update code as needed 9. Once reviewed and approved, a RAPIDS developer will merge your pull request @@ -65,6 +65,6 @@ For all others: 1. Find the project board for the next release (named `[version] Release`) 2. Scroll right to find the `PR-Needs Review` -3. Review the PR (Make sure you follow the [Code of Conduct]({% link resources/conduct.md %})) +3. Review the PR (Make sure you follow the [Code of Conduct]({{< relref "../maintainers/conduct.md" >}})) If you are project lead, also review pull requests in the `PR-Reviewer Approved` column and merge as needed. diff --git a/content/docs/contributing/issues.md b/content/docs/contributing/issues.md index 4afb2dee..0c4243c8 100644 --- a/content/docs/contributing/issues.md +++ b/content/docs/contributing/issues.md @@ -1,6 +1,6 @@ --- title: Issues -linkTitle: Issues +linkTitle: Issues description: Gateway to the RAPIDS documentation content type: docs weight: 10 @@ -11,8 +11,8 @@ weight: 10 Overview of the best practices for creating and updating issues for RAPIDS projects. ### See also -- [Contributing Code]({% link contributing/code.md %}) -- [Pull Requests]({% link contributing/prs.md %}) +- [Contributing Code]({{< relref "code.md" >}}) +- [Pull Requests]({{< relref "prs.md" >}}) ## Create an issue @@ -64,7 +64,7 @@ If an issue is blocked due to another issue or pull request do the following: ## Lifecycle -Issues are either assigned by team leads or picked in priority order. If you are unsure what to work on, follow this [guide]({% link contributing/code.md %}#what-do-i-work-on). +Issues are either assigned by team leads or picked in priority order. If you are unsure what to work on, follow this [guide]({{< relref "code.md#what-do-i-work-on" >}}). When you begin work on an issue, update the labels to remove 1 - On Deck or 0 - Backlog and add 2 - In Progress. diff --git a/content/docs/contributing/prs.md b/content/docs/contributing/prs.md index 662e5922..4b72f0f6 100644 --- a/content/docs/contributing/prs.md +++ b/content/docs/contributing/prs.md @@ -1,6 +1,6 @@ --- title: Pull Requests -linkTitle: PRs +linkTitle: PRs description: Gateway to the RAPIDS documentation content type: docs weight: 10 @@ -12,9 +12,9 @@ Overview of creating a pull request for a RAPIDS project. ### See also -- [Issues]({% link contributing/issues.md %}) -- [Code Contributions]({% link contributing/code.md %}) -- [Changelog]({% link resources/changelog.md %}) +- [Issues]({{< relref "issues.md" >}}) +- [Code Contributions]({{< relref "code.md" >}}) +- [Changelog]({{< relref "../maintainers/changelog.md" >}}) ## Create a pull request @@ -58,7 +58,7 @@ The description should provide any context not found in the issue description. ### Comments -All pull request comments and reviews must follow the [Code of Conduct]({% link resources/conduct.md %}) +All pull request comments and reviews must follow the [Code of Conduct]({{< relref "../maintainers/conduct.md" >}}) ## Lifecycle diff --git a/content/docs/maintainers/_index.md b/content/docs/maintainers/_index.md index a0992568..e664021d 100644 --- a/content/docs/maintainers/_index.md +++ b/content/docs/maintainers/_index.md @@ -10,17 +10,17 @@ RAPIDS projects use an established set of guidelines and procedures for all proj ## Release v{{ site.data.releases.nightly.version }} Schedule -**NOTE:** *Dates are subject to change at anytime. Completed release schedules are posted [here]({% link releases/schedule.md %}).* +**NOTE:** *Dates are subject to change at anytime. Completed release schedules are posted [here]({{< relref "../releases/schedule.md" >}}).* Phase | Start | End | Duration -- | -- | -- | -- Development (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.nightly.cudf_dev.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_dev.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_dev.days }} days Development (others) | {{ site.data.releases.nightly.other_dev.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_dev.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_dev.days }} days -[Burn Down]({% link releases/process.md %}#burn-down)(cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.nightly.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_burndown.days }} days -[Burn Down]({% link releases/process.md %}#burn-down) (others) | {{ site.data.releases.nightly.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_burndown.days }} days -[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) [^1] | {{ site.data.releases.nightly.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_codefreeze.days }} days -[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (others) | {{ site.data.releases.nightly.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_codefreeze.days }} days -[Release]({% link releases/process.md %}#releasing) | {{ site.data.releases.nightly.release.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.release.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.release.days }} days +[Burn Down]({{< relref "../releases/process.md#burn-down" >}})(cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.nightly.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_burndown.days }} days +[Burn Down]({{< relref "../releases/process.md#burn-down" >}}) (others) | {{ site.data.releases.nightly.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_burndown.days }} days +[Code Freeze/Testing]({{< relref "../releases/process.md#code-freeze" >}}) (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) [^1] | {{ site.data.releases.nightly.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_codefreeze.days }} days +[Code Freeze/Testing]({{< relref "../releases/process.md#code-freeze" >}}) (others) | {{ site.data.releases.nightly.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_codefreeze.days }} days +[Release]({{< relref "../releases/process.md#releasing" >}}) | {{ site.data.releases.nightly.release.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.release.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.release.days }} days ## _PROPOSED_ Release v{{ site.data.releases.next_nightly.version }} Schedule @@ -28,10 +28,10 @@ Phase | Start | End | Duration -- | -- | -- | -- Development (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.next_nightly.cudf_dev.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_dev.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_dev.days }} days Development (others) | {{ site.data.releases.next_nightly.other_dev.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_dev.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_dev.days }} days -[Burn Down]({% link releases/process.md %}#burn-down)(cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.next_nightly.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_burndown.days }} days -[Burn Down]({% link releases/process.md %}#burn-down) (others) | {{ site.data.releases.next_nightly.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_burndown.days }} days -[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) [^1] | {{ site.data.releases.next_nightly.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_codefreeze.days }} days -[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (others) | {{ site.data.releases.next_nightly.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_codefreeze.days }} days -[Release]({% link releases/process.md %}#releasing) | {{ site.data.releases.next_nightly.release.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.release.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.release.days }} days +[Burn Down]({{< relref "../releases/process.md#burn-down" >}})(cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.next_nightly.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_burndown.days }} days +[Burn Down]({{< relref "../releases/process.md#burn-down" >}}) (others) | {{ site.data.releases.next_nightly.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_burndown.days }} days +[Code Freeze/Testing]({{< relref "../releases/process.md#code-freeze" >}}) (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) [^1] | {{ site.data.releases.next_nightly.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_codefreeze.days }} days +[Code Freeze/Testing]({{< relref "../releases/process.md#code-freeze" >}}) (others) | {{ site.data.releases.next_nightly.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_codefreeze.days }} days +[Release]({{< relref "../releases/process.md#releasing" >}}) | {{ site.data.releases.next_nightly.release.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.release.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.release.days }} days [^1]: Cross-library dependencies are pinned during this time-frame. For example: Dask and Distributed. diff --git a/content/docs/maintainers/burn-down-guide.md b/content/docs/maintainers/burn-down-guide.md index 8afa25ac..f2e2f1b7 100644 --- a/content/docs/maintainers/burn-down-guide.md +++ b/content/docs/maintainers/burn-down-guide.md @@ -8,7 +8,7 @@ weight: 10 ## Overview -This is a guide for the steps required to perform at the start of [burn down]({% link releases/process.md %}#burn-down). +This is a guide for the steps required to perform at the start of [burn down]({{< relref "../releases/process.md#burn-down" >}}). Given the current development version is `v0.A.0`, then the next version is `v0.B.0` where `B=A+1`. diff --git a/content/docs/maintainers/forward-merger.md b/content/docs/maintainers/forward-merger.md index 5c177719..823136ff 100644 --- a/content/docs/maintainers/forward-merger.md +++ b/content/docs/maintainers/forward-merger.md @@ -35,8 +35,8 @@ git commit -am "Merge branch-{{ site.data.releases.stable.version }} into branch git push branch-{{ site.data.releases.nightly.version }}-merge-{{ site.data.releases.stable.version }} ``` -Once this is done, open a PR that targets the new default branch (`branch-{{ site.data.releases.nightly.version }}` in this example) with your changes. +Once this is done, open a PR that targets the new default branch (`branch-{{ site.data.releases.nightly.version }}` in this example) with your changes. -**IMPORTANT**: When merging this PR, do not use the [auto-merger]({% link resources/auto-merger.md %}) (i.e. the `/merge` comment). Instead, an admin must manually merge by changing the merging strategy to `Create a Merge Commit`. Otherwise, history will be lost and the branches become incompatible. +**IMPORTANT**: When merging this PR, do not use the [auto-merger]({% relref "auto-merger.md" %}) (i.e. the `/merge` comment). Instead, an admin must manually merge by changing the merging strategy to `Create a Merge Commit`. Otherwise, history will be lost and the branches become incompatible. -Once this PR is approved and merged, the original forward-merger PR should automatically be merged since it will contain the same commit hashes. \ No newline at end of file +Once this PR is approved and merged, the original forward-merger PR should automatically be merged since it will contain the same commit hashes. diff --git a/content/docs/maintainers/git.md b/content/docs/maintainers/git.md index 78836e08..0d6dde75 100644 --- a/content/docs/maintainers/git.md +++ b/content/docs/maintainers/git.md @@ -12,9 +12,9 @@ Details on our git branching method used for RAPIDS and our style conventions fo ### See also -* [Versioning and Tagging]({% link resources/versions.md %}) -* [Hotfix releases]({% link releases/hotfix.md %}) -* [Major and minor releases]({% link releases/process.md %}) +* [Versioning and Tagging]({{< relref "versions.md" >}}) +* [Hotfix releases]({{< relref "hotfix.md" >}}) +* [Major and minor releases]({{< relref "process.md" >}}) ## Git branching @@ -24,7 +24,7 @@ Our development approach involves protecting the `main` branch so that it become ### Development workflow -All PRs are merged into a release branch named `branch-M.B` where `M` is the major version and `B` is the minor version number. Release branches are created from the previous release branch when the decision has been made to **freeze** the release. +All PRs are merged into a release branch named `branch-M.B` where `M` is the major version and `B` is the minor version number. Release branches are created from the previous release branch when the decision has been made to **freeze** the release. To **freeze** a release branch is to stop new development for the release, and focus on completing outstanding features and any bugs discovered from testing. Once this **freeze** happens a new branch `branch-M.C` (where `C=B+1`) is created so development can continue. Updates to `branch-M.B` can be merged as needed to `branch-M.C`, but generally will wait until the release is finished. This means that `branch-M.X` (where `X` is the highest minor version) the latest and greatest code. @@ -62,4 +62,4 @@ Files that are `not required` should be stored in S3 so the limited number of de It is important to choose the appropriate storage mechanism from the beginning because transitioning from git to git LFS or S3 requires rewriting git history. -If you need data uploaded to S3, simply file an Ops issue. \ No newline at end of file +If you need data uploaded to S3, simply file an Ops issue. diff --git a/content/docs/maintainers/github-actions.md b/content/docs/maintainers/github-actions.md index 515658bf..5f45c423 100644 --- a/content/docs/maintainers/github-actions.md +++ b/content/docs/maintainers/github-actions.md @@ -37,7 +37,7 @@ The chart below provides an overview of how each workflow file is used. | - `branch-*` Merges
- Releases | - `build.yaml` | ✅ | ❌ | ✅ | | - Nightlies | - `build.yaml`
- `test.yaml` | ✅ | ✅ | ✅ | -Although release workflows don't run tests, they do go through a week of nightly testing to ensure everything works as expected. See [this page]({% link releases/process.md %}) for more details about the release process. +Although release workflows don't run tests, they do go through a week of nightly testing to ensure everything works as expected. See [this page]({{< relref "../releases/process.md" >}}) for more details about the release process. ## How Nightlies Are Triggered diff --git a/content/docs/maintainers/style.md b/content/docs/maintainers/style.md index 63e38eba..b30d04e9 100644 --- a/content/docs/maintainers/style.md +++ b/content/docs/maintainers/style.md @@ -22,4 +22,4 @@ Individual projects should configure `flake8` to suit their needs, for example t Git commit messages should convey the change succinctly, but with enough detail to be understood without extra context. -See the [Git Methodology]({% link resources/git.md %}#git-commits) for further details. +See the [Git Methodology]({{< relref "git.md#git-commits" >}}) for further details. diff --git a/content/docs/maintainers/testing.md b/content/docs/maintainers/testing.md index 80ec4f72..360a606d 100644 --- a/content/docs/maintainers/testing.md +++ b/content/docs/maintainers/testing.md @@ -16,7 +16,7 @@ Summary of the testing practices used by RAPIDS projects. Overall goal, follow the open source ecosystem for infrastructure choices ### GitHub Actions -See docs [here]({% link resources/github-actions.md %}). +See docs [here]({{< relref "../maintainers/github-actions.md" >}}). ### GitHub @@ -65,7 +65,7 @@ See docs [here]({% link resources/github-actions.md %}). ## Datasets -- Many tests depend on the presence of specific datasets in order to properly verify code correctness. See [datasets]({% link maintainers/datasets.md %}) for more details. +- Many tests depend on the presence of specific datasets in order to properly verify code correctness. See [datasets]({{< relref "datasets.md" >}}) for more details. ## Integration / Workflow Testing and Benchmarking diff --git a/content/docs/releases/hotfix.md b/content/docs/releases/hotfix.md index 2e33e7bc..ccd9037c 100644 --- a/content/docs/releases/hotfix.md +++ b/content/docs/releases/hotfix.md @@ -13,8 +13,8 @@ Summary of the RAPIDS release process for hotfixes. ### See also -* [Hotfix versioning]({% link resources/versions.md %}) -* [Major and minor releases]({% link releases/process.md %}) +* [Hotfix versioning]({{< relref "../maintainers/versions.md" >}}) +* [Major and minor releases]({{< relref "process.md" >}}) ## Hotfixes @@ -63,7 +63,7 @@ Developers Project Leads {: .label .label-blue} -1. During [triage]({% link releases/triage.md %}), identify potential hotfixes +1. During [triage]({{< relref "triage.md" >}}), identify potential hotfixes 2. Ensure that the [hotfix criteria](#criteria) is met 3. Assign the issue and track its progress 4. Notify Operations that a hotfix is being worked on diff --git a/content/docs/releases/planning.md b/content/docs/releases/planning.md index 98349e0e..1ba2dace 100644 --- a/content/docs/releases/planning.md +++ b/content/docs/releases/planning.md @@ -13,8 +13,8 @@ Summary of the release planning process used by RAPIDS projects. ### See also -- [Versions and Tags]({% link resources/versions.md %}) -- [Release Process]({% link releases/process.md %}) +- [Versions and Tags]({{< relref "../maintainers/versions.md" >}}) +- [Release Process]({{< relref "process.md" >}}) ## Planning process @@ -23,7 +23,7 @@ Summary of the release planning process used by RAPIDS projects. **NOTE:** The processes below use the current release of `M.A`, the next release of `M.B` and future release `M.C` (where `B=A+1`, `C=B+1`) for examples. Releases are planned in two phases: -1. `Fuzzy planning` from [Issue Triage]({% link releases/triage.md %}) which is ongoing. +1. `Fuzzy planning` from [Issue Triage]({{< relref "triage.md" >}}) which is ongoing. 2. `Focus planning` which starts when release `M.B` is **frozen**. ### Release boards @@ -36,7 +36,7 @@ Each Release board has the following columns: | Column | Purpose | |:-------|:--------| -| Issue-Needs prioritizing | Issues that have gone through the [Issue Triage]({% link releases/triage.md %}) process and need to be prioritized | +| Issue-Needs prioritizing | Issues that have gone through the [Issue Triage]({{< relref "triage.md" >}}) process and need to be prioritized | | Issue-P0 | Issues that should be worked on first | | Issue-P1 | Issues that should be worked on only if all `P0` issues are complete or assigned | | Issue-P2 | Issues that should be worked on only if all `P1` issues are complete or assigned | diff --git a/content/docs/releases/process.md b/content/docs/releases/process.md index e985f5e0..48b808f3 100644 --- a/content/docs/releases/process.md +++ b/content/docs/releases/process.md @@ -12,12 +12,12 @@ Summary of the RAPIDS release process for major and minor releases. ### See also -* [Git branching model]({% link resources/git.md %}) -* [Major and minor release versioning]({% link resources/versions.md %}) +* [Git branching model]({{< relref "../maintainers/git.md" >}}) +* [Major and minor release versioning]({{< relref "../maintainers/versions.md" >}}) ## Git branching model -RAPIDS uses a custom git branching model, adapted from git-flow to leverage the tools GitHub provides and also focus on release-driven development. From more details see our guide for our [git branching]({% link resources/git.md %}) methodology. +RAPIDS uses a custom git branching model, adapted from git-flow to leverage the tools GitHub provides and also focus on release-driven development. From more details see our guide for our [git branching]({{< relref "../maintainers/git.md" >}}) methodology. ### Migrating projects @@ -37,7 +37,7 @@ The `burn down date` will always be several days before the `code freeze date` w ### Hotfixes -Hotfixes have their own process and are described [here]({% link releases/hotfix.md %}). +Hotfixes have their own process and are described [here]({{< relref "hotfix.md" >}}). ## Burn down @@ -71,12 +71,12 @@ Operations 3. Create release `M.C` project board 4. Notify project leads process is complete -Also see the [Burn down guide]({% link resources/burn-down-guide.md %}) +Also see the [Burn down guide]({{< relref "../maintainers/burn-down-guide.md" >}}) ## Code freeze -Code freeze is the process when the release undergoes thorough testing. Pull requests are no longer accepted into the development branch. An exception may be made for [hotfix]({% link releases/hotfix.md %}) issues. All pull requests from Burn Down should be merged before Code Freeze begins or be moved to the next release. +Code freeze is the process when the release undergoes thorough testing. Pull requests are no longer accepted into the development branch. An exception may be made for [hotfix]({{< relref "hotfix.md" >}}) issues. All pull requests from Burn Down should be merged before Code Freeze begins or be moved to the next release. ### Timing For the selection of a `code freeze date`, the general guidelines should be followed: diff --git a/content/docs/releases/schedule.md b/content/docs/releases/schedule.md index d991c2c2..a853e32b 100644 --- a/content/docs/releases/schedule.md +++ b/content/docs/releases/schedule.md @@ -8,7 +8,7 @@ weight: 10 ## Current release -The current release schedule is posted on the [RAPIDS Maintainers Docs]({% link maintainers/maintainers.md %}) page. +The current release schedule is posted on the [RAPIDS Maintainers Docs]({{< relref "../maintainers/_index.md" >}}) page. ## Completed Releases @@ -35,11 +35,11 @@ Phase | Start | End | Duration -- | -- | -- | -- Development (cuDF/RMM{% if release.version >= '23.06' %}/rapids-cmake/cugraph-ops/raft{% endif %}) | {{ release.cudf_dev.start | date: "%a, %b %e, %Y" }} | {{ release.cudf_dev.end | date: "%a, %b %e, %Y" }} | {{ release.cudf_dev.days }} days Development (others) | {{ release.other_dev.start | date: "%a, %b %e, %Y" }} | {{ release.other_dev.end | date: "%a, %b %e, %Y" }} | {{ release.other_dev.days }} days -[Burn Down]({% link releases/process.md %}#burn-down)(cuDF/RMM{% if release.version >= '23.06' %}/rapids-cmake/cugraph-ops/raft{% endif %}) | {{ release.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ release.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ release.cudf_burndown.days }} days -[Burn Down]({% link releases/process.md %}#burn-down) (others) | {{ release.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ release.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ release.other_burndown.days }} days -[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (cuDF/RMM/rapids-cmake/cugraph-ops/raft) | {{ release.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ release.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ release.cudf_codefreeze.days }} days -[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (others) | {{ release.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ release.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ release.other_codefreeze.days }} days -[Release]({% link releases/process.md %}#releasing) | {{ release.release.start | date: "%a, %b %e, %Y" }} | {{ release.release.end | date: "%a, %b %e, %Y" }} | {{ release.release.days }} days +[Burn Down]({{< relref "process.md#burn-down" >}})(cuDF/RMM{% if release.version >= '23.06' %}/rapids-cmake/cugraph-ops/raft{% endif %}) | {{ release.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ release.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ release.cudf_burndown.days }} days +[Burn Down]({{< relref "process.md#burn-down" >}}) (others) | {{ release.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ release.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ release.other_burndown.days }} days +[Code Freeze/Testing]({{< relref "process.md#code-freeze" >}}) (cuDF/RMM/rapids-cmake/cugraph-ops/raft) | {{ release.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ release.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ release.cudf_codefreeze.days }} days +[Code Freeze/Testing]({{< relref "process.md#code-freeze" >}}) (others) | {{ release.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ release.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ release.other_codefreeze.days }} days +[Release]({{< relref "process.md#releasing" >}}) | {{ release.release.start | date: "%a, %b %e, %Y" }} | {{ release.release.end | date: "%a, %b %e, %Y" }} | {{ release.release.days }} days {% endif %} {% endif %} {% endfor %} diff --git a/content/docs/releases/triage.md b/content/docs/releases/triage.md index 3cc22189..609ce938 100644 --- a/content/docs/releases/triage.md +++ b/content/docs/releases/triage.md @@ -16,7 +16,7 @@ RAPIDS projects are continuously triaging new issues and re-triaging existing is ## Triage process -### Timing +### Timing - Label and prioritize new issues within **2 business days** - Re-prioritize existing issues **every week** using the project's issue tracking boards @@ -45,7 +45,7 @@ Each permanent project board (Bug Squashing, Feature Planning,and Other Issues) See [Release Board](https://docs.rapids.ai/releases/planning/) for the column definition that pertain to the Release Board. -**IMPORTANT:** +**IMPORTANT:** In leveraging the tracking boards for issue management, project leads can _schedule_ issues by placing them in the appropriate column and then _prioritize_ issues by dragging & sorting the issues from highest priority at the top of the column to lowest at the bottom. We can also use labels on the issues/PRs to filter and _prioritize_ work. By placing the issues in one of these permanent boards (Bug Squashing, Feature Planning, or Other Issues) filers and the community will see updates to the issue and can get a sense of when they can expect feedback. For example, on a given issue a user may see `Future release in Other Issues` and this allows the filer or the community to comment on if they believe the issue should be addressed faster. @@ -94,7 +94,7 @@ Project Leads - Daily ### Prioritize & schedule -Once issues have been triaged, we can prioritize and schedule them for a release. +Once issues have been triaged, we can prioritize and schedule them for a release. **IMPORTANT:** By leveraging the tracking boards for issues, project leads can _schedule_ issues by placing them in the appropriate column and then _prioritize_ issues by dragging & sorting the issues from highest priority at the top of the column to lowest at the bottom. @@ -116,7 +116,7 @@ Project Leads - Weekly #### Hotfix -1. Verify the issue is a [hotfix]({% link releases/hotfix.md %}). +1. Verify the issue is a [hotfix]({{< relref "hotfix.md" >}}). 2. Identify the project lead(s) needed to resolve the hotfix. 3. Host a meeting about the proposed hotfix with the stakeholders and operations to determine the path forward. 4. Assign a developer or team to fix the issue ASAP. diff --git a/content/notices/notices.md b/content/notices/notices.md index d0a36a1b..dd372030 100644 --- a/content/notices/notices.md +++ b/content/notices/notices.md @@ -13,7 +13,7 @@ Notices are our means to communicate and document changes in the project to cont {: .fs-6 .fw-300 } ## Notice Types - + Type | Code | Intended Audience | Purpose --- | --- | --- | --- [RAPIDS Developer Notice]({% link notices/rdn.md %}) | **RDN** | Contributors & Core Developers | Communicate updates to development processes diff --git a/content/notices/rgn0003.md b/content/notices/rgn0003.md index 7e9f728b..28bb854f 100644 --- a/content/notices/rgn0003.md +++ b/content/notices/rgn0003.md @@ -39,5 +39,5 @@ dependencies instead. ## Impact -See our updated [release schedule]({% link maintainers/maintainers.md %}) for +See our updated [release schedule]({{< relref "../../docs/maintainers/_index.md" >}}) for `v0.15` diff --git a/content/notices/rgn0006.md b/content/notices/rgn0006.md index aac7f87a..4fcdd10b 100644 --- a/content/notices/rgn0006.md +++ b/content/notices/rgn0006.md @@ -30,5 +30,5 @@ The RAPIDS `v0.16` release date has been extended for 1 week to 2020-10-21 ## Impact -See our updated [release schedule]({% link maintainers/maintainers.md %}) for +See our updated [release schedule]({{< relref "../../docs/maintainers/_index.md" >}}) for `v0.16` diff --git a/content/notices/rgn0008.md b/content/notices/rgn0008.md index 4fc35d18..0cfb3ec7 100644 --- a/content/notices/rgn0008.md +++ b/content/notices/rgn0008.md @@ -31,7 +31,7 @@ encountered in [RDN 2](/notices/rdn0002) ## Impact -- See our updated [release schedule]({% link maintainers/maintainers.md %}) for +- See our updated [release schedule]({{< relref "../../docs/maintainers/_index.md" >}}) for `v0.18` - Refer to [RDN 2](/notices/rdn0002) for more details on gcc `7.5.0` from-source build changes needed in `v0.18+` diff --git a/content/notices/rgn0009.md b/content/notices/rgn0009.md index b61648ca..37f79c69 100644 --- a/content/notices/rgn0009.md +++ b/content/notices/rgn0009.md @@ -34,4 +34,4 @@ The release is being extended in order to fix a [bug](https://github.com/rapidsa ## Impact -See our updated [release schedule]({% link maintainers/maintainers.md %}) for `v0.19` +See our updated [release schedule]({{< relref "../../docs/maintainers/_index.md" >}}) for `v0.19`