ROCm/TheRock is production; Retire ROCm/ROCm; TheRock is now ROCm

[saadrahim]

Motivation

RFC to discuss future of ROCm/ROCm repository.

Technical Details

Non technical

Test Plan

TBD

Test Result

NA

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/TheRock/blob/main/CONTRIBUTING.md.

[therock-pr-bot]

❌ PR Check — Action Required

Check	Status	Details
📝 PR Title/Description	❌ Fail	Error: PR description must reference a JIRA ID, ISSUE ID, or a GitHub closing keyword. Expected: include a JIRA ID / ISSUE ID line (separator : or -, or omitted; value may be a JIRA key, a number with/without #, or a link), OR a closing keyword + issue reference. Accepted examples: • JIRA ID : TESTAUTO-6039 • JIRA ID - #330 • JIRA ID #330 • JIRA ID (on separate line) ROCM-25757 • ISSUE ID : TESTUTO-3334 • ISSUE ID #3334 • ISSUE ID - TESTAUTO-3433 • ISSUE ID (on separate line) AIRUNTIME-2352 • ISSUE ID : https://github.com/<org_name>/<repo_name>/issues/1234 • Closes #10 • Fixes octo-org/octo-repo#100 • Resolves: #123 • #123 • https://github.com/<org_name>/<repo_name>/issues/123 Current: no valid JIRA/ISSUE/closing-keyword reference found
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	PR does not contain code files — Unit Test auto-passed
🔎 pre-commit	❌ Fail	Error: Check concluded with failure.
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—

⚠️ 2 policy check(s) failed. Please address the issues above before this PR can be Reviewed.

🚫 Please fix the failed policies

• ❌ PR Title/Description
• ❌ pre-commit

The Not ready to Review label was added to this PR. Once all policies pass, the label is removed automatically.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

[therock-pr-bot]

🚫 Please fix the failed policies before requesting reviews.

The following policy checks failed:

• ❌ PR Title/Description

The Not ready to Review label has been added to this PR.
Once all policies pass, the label will be removed automatically.

[marbre]

This is a way larger churn then one initially thinks. We have cross-repository interaction via Quartz, authentication is based on the exact repo name, resources are explicitly registered to or enabled for the repository, not to mention docs. All this can of course be changed but it is not a simple rename in GitHub settings and rather real work which needs to be validated carefully to not break the entire system.

[saadrahim]

This is a way larger churn then one initially thinks. We have cross-repository interaction via Quartz, authentication is based on the exact repo name, resources are explicitly registered to or enabled for the repository, not to mention docs. All this can of course be changed but it is not a simple rename in GitHub settings and rather real work which needs to be validated carefully to not break the entire system.

I was hoping that the GitHub redirection keeps everything working. This may be high cost request as you suggest I am wrong. Let's think about it.

[stellaraccident]

Thanks. You may proceed to execute this at any time so long as you have @ScottTodd saying it is ok.

[stellaraccident]

Call it legacy-rocm-build?

[stellaraccident]

Let's do this carefully. I'm supportive but the DevOps team will need to do it at their leisure to avoid surprises at critical times. It's one of those things that should be fine but GH changes are test in prod, and need the owners to time it so that they can fix any issues.

[ScottTodd]

I can see ways we could pull this off, but I'm hesitant given:

• TheRock as a project name has developed a following both within ROCm developers and some sections of the user community
• It's useful to have a name for the build and CI system components that isn't just "ROCm"
• The current https://github.com/ROCm/ROCm hosts policies that apply across the full project and github organization. Do we want to merge those with what exists here?

[ScottTodd]

We currently have an organization-wide pull request template at https://github.com/ROCm/.github/blob/main/.github/pull_request_template.md with this content:

## Submission Checklist

- [ ] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

That links to https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests, which would be replaced with https://github.com/ROCm/TheRock/blob/main/CONTRIBUTING.md after the repository renames.

I recently made some edits to the contributing guide in TheRock focused contributing to TheRock itself, so we'd want to re-evaluate that if we make this change. In particular:

• The https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md page is written to apply to all projects (that don't have their own local contributing guide).
  • We could point to the file in this repository but lead with general guidance and then include TheRock-specific guidance.
  • We could add a new common CONTRIBUTING.md in https://github.com/ROCm/.github or other repository (rocm-legacy?) if we want a dedicated location for the "default" contributing guide
• There is currently some stronger language for TheRock itself like "TheRock uses GitHub as the source of truth for all issue tracking, project planning, and code contributions." that while I'd like to apply to all of ROCm, that would be a larger discussion.

---

I'm also concerned about the "history-preserving migration of README content, GOVERNANCE.md, CONTRIBUTING.md" detail. How would that work? We currently have substantial content and history for README.md and CONTRIBUTING.md in this repository.

[ScottTodd]

I don't think we should reconcile https://github.com/ROCm/ROCm/blob/develop/CHANGELOG.md into https://github.com/ROCm/TheRock/blob/main/RELEASES.md as the files have different purposes. We can add a new CHANGELOG.md as needed.

[saadrahim]

Agreed, will update.

[ScottTodd]

This is a way larger churn then one initially thinks. We have cross-repository interaction via Quartz, authentication is based on the exact repo name, resources are explicitly registered to or enabled for the repository, not to mention docs. All this can of course be changed but it is not a simple rename in GitHub settings and rather real work which needs to be validated carefully to not break the entire system.

I was hoping that the GitHub redirection keeps everything working. This may be high cost request as you suggest I am wrong. Let's think about it.

Yeah this will be tricky. The GitHub redirect is enough for some items but not all. I'm worried about the authentication for cloud project resources in particular. (That's solvable with a few minute-hours of poking settings in the cloud project(s), but it will be disruptive)

[saadrahim]

My request is to do this someday in the next couple of quarters. Ideally during some quiet period. Maybe after the last ROCm release before the holidays.

With a lot of preplanning and testing. The name changes I am suggesting are entirely reversible in case things go wrong.

[ScottTodd]

I think there's still value in the "TheRock" name referring to the build and CI systems. How would we keep that with this repository rename?

A few spots where it is particularly relevant:

• "TheRock CI" in rocm-libraries/rocm-systems/etc. https://github.com/ROCm/rocm-libraries/blob/develop/.github/workflows/therock-ci.yml
• Docs/code/etc. in this repository (https://github.com/ROCm/TheRock/tree/main/docs/development)
• Some code in other repositories uses the name in variables, file names, script conventions, etc.
  • -DHIPBLASLT_ENABLE_THEROCK: https://github.com/ROCm/rocm-libraries/blob/0e2e6b4e1bcb14cc04306324878374dcb967a8e9/projects/hipblaslt/clients/common/CMakeLists.txt#L24
  • -DTHEROCK_SANITIZER: https://github.com/ROCm/rocm-libraries/blob/0e2e6b4e1bcb14cc04306324878374dcb967a8e9/projects/composablekernel/CMakeLists.txt#L39
  • THEROCK_INSTALL_RPATH_ORIGIN: https://github.com/ROCm/rocm-libraries/blob/0e2e6b4e1bcb14cc04306324878374dcb967a8e9/dnn-providers/hip-kernel-provider/src/CMakeLists.txt#L69-L71

Brainstorming:

• We could keep the name in all the places it currently exists, disambiguate in the repository README
• We could rebrand as "ROCm CI", if that name carries enough meaning
• Move sections of this repository to a TheRock / therock / the-rock subfolder

[saadrahim]

I think we keep TheRock as a name, similar to Bazel for PyTorch. I know the analogy is a bit of stretch but that's how I think of it.

I don't think we change any env vars or things tied to TheRock. TheRock still exists but refers to our build/CI system. We don't go stripping out every reference to it.

[ScottTodd]

Here's another option: strip https://github.com/ROCm/ROCm down to just organization-wide / product-wide documentation and discussion. Keep https://github.com/ROCm/TheRock focused on the build system. That won't solve the problem of having two places to file issues, but I also sorta want to keep "why is this math library slow" style issues out of TheRock (direct people to rocm-libraries instead?)

[saadrahim]

GitHub issues can be move between projects in an organization. I think we can teach the triage team move things that don't belong in ROCm/ROCm or ROCm/TheRock to rocm-libraries.

But I strongly believe that despite the cost of merging, we need only one top level repository for entry point for all.

[saadrahim]

Internal users and customers are getting very confused between our two entry points TheRock and ROCm.