rocm-systems: RCCL is on disk and missing from the table, four components are listed under two names, and no LICENSE file ships at the root

RCCL sits in the tree and nowhere in the status table

The Structure section prints the directory layout:

projects/
  amdsmi/
  aqlprofile/
  clr/
  hip/
  hipfile/
  hipother/
  hip-tests/
  rccl/
  rdc/
  rocdbgapi/
  rocdecode/
  rocjpeg/
  rocm-core
  rocminfo/
  rocmsmilib/
  rocprofiler/
  rocprofiler-compute/
  rocprofiler-register/
  rocprofiler-sdk/
  rocprofiler-systems/
  rocr-debug-agent/
  rocrruntime/
  rocshmem/
  roctracer/

That is twenty-four directories. The migration status table above it lists twenty-three components, and `rccl` is not among them. So the collective communications library is present in the working tree with no row describing its source of truth, its migration state, or whether it builds here. This is the one component whose absence changes what the table means, because a reader using the table to decide whether a project has moved has no way to learn that one has.

Four components carry two different names in the two lists

A section titled Nomenclature states that project names have been standardised to match the casing and punctuation of released packages, removing the inconsistent camel-casing and hyphen and join characters used in legacy repositories. That is the section where you would check the claim, and the two lists a few lines apart do not agree. The table says `rocm-smi-lib`, `rocr-debug-agent`, `rocr-runtime`, and `rocm-core`. The tree says `rocmsmilib/`, `rocr-debug-agent/`, `rocrruntime/`, and `rocm-core`. Two names lost their join character in the directory layout and kept it in the table. Six entries in both lists still carry a hyphen, including `hip-tests`, `rocprofiler-compute`, and `rocr-debug-agent`. And `rocm-core` is the only entry in the tree without a trailing slash, which in a list where every other line has one reads as a typo rather than a naming decision.

Every component is Completed and the old repository still does releases

All twenty-three rows in the migration table read Completed, and the key defines that state as fully migrated and integrated, with this super-repo to be considered the source of truth for the project. The same key adds a clause to the same bullet: the old repository may still be used for release activities. So for every single component there are two repositories, one of which is the declared source of truth and the other of which is where releases come from. The release history bears that out. The three most recent tags are `therock-7.14.1`, `therock-10.0`, and `therock-7.14`, all named for the build system rather than for any component, and the version line steps from a 7.x series straight to 10.0. Not one of the twenty-three migrated projects has a release of its own here.

Fourteen CI cells are blank, two say None, and the key explains neither

The key defines three migration states and says the table also points to current CI health. The CI column uses four different states, only one of which is explained. Seven rows carry workflow badge links, which is the informative case. Two rows, `rocdbgapi` and `rocr-debug-agent`, say None, which reads as a deliberate negative. The remaining fourteen rows, including `hip`, `rocm-core`, `rocminfo`, `rocm-smi-lib`, `roctracer`, and `rocshmem`, have an empty cell. A blank is not a value, so a reader cannot tell whether those components build on every push, build on no push, or build somewhere else. The migration status beside them says Completed in every case. The gap between the two columns is where a stale component would hide, and it is fourteen rows wide.

A schedule table with a header and nothing under it

Below the status table sits a section titled Tentative migration schedule, which contains a two-line table: a header naming a Component and a Tentative Date column, and a separator row. Then the page says in italics that the remaining schedule is to be determined. There are no rows. That is the correct state for a project where every row says Completed, and it is also the entire remaining content of the section, so a reader looking for a roadmap finds a heading and an apology. The repository does carry a `docs/` directory and a `CONTRIBUTING.md`, so planning material may exist there, but the page does not point at either. The section that would tell a contributor where to work is the one with no content in it.

No licence, git submodules, and DVC in the root of a single source of truth

The root of the repository holds `.dvc/`, `.dvcignore`, `.git-blame-ignore-revs`, `.github/`, `.gitignore`, `.gitmodules`, `.pre-commit-config.yaml`, `CONTRIBUTING.md`, `README.md`, `docs/`, `emulation/`, `experimental/`, `profilers/`, `projects/`, `python/`, `runtimes/`, `shared/`, `test/`, and `tools/`. Three details there are worth a second look. There is no LICENSE file and the licence is recorded as unknown, in a repository that merged twenty-three projects each carrying its own terms. There is a `.gitmodules`, so at least one dependency is still a pointer to another repository, which sits oddly with the consolidation claim. And there is `.dvc/` with a `.dvcignore`, so some inputs are tracked by a data version control system rather than by git, with nothing on the page saying which. The blame-ignore file is the expected artefact of a mass migration that rewrote history.

Editorial conclusion

This is an in-flight consolidation, not a finished one, and the table says so in the only way it can: a schedule section with a header and no rows. If you are picking a component to depend on, check whether it has a CI badge row before assuming it builds here, because fourteen of twenty-three rows leave that cell blank and two say None. Do not rely on the directory names to find a component either, since the table and the tree spell four of them differently. And note that every component is Completed while the old repository may still be used for release activities, which means the artefacts you install are not necessarily built from this tree. Take the licence from the component you actually consume.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes