All 25 migration rows say Completed, but the hipdnn folder has none

Twenty-five rows say Completed and one folder has no row

The status table names 25 components, running from composablekernel through rpp, and every one of them carries the same single word: Completed. Under the key printed above that table, Completed means fully migrated and integrated, that this super-repo should be treated as the source of truth for that project, and that the old repository may still be used for certain release activities. The directory tree adds one name the table never mentions. hipdnn sits under projects/ between hipcub and hipfft. Counting the other way, projects/ holds 22 folders and shared/ holds 4, so 26 directories against 25 rows. The key also defines In Progress and Pending states with instructions about which repository to trust and where not to open pull requests, and neither state appears anywhere in the table. Both instruction sets describe a phase this repository says it has already finished.

Eleven root entries the structure section never mentions

The Structure section says the repository is organized in one way, prints two directory lists, and stops there:

projects/
  composablekernel/
  hipblas/
  hipblas-common/
  hipblaslt/
  hipcub/
  hipdnn/
  hipfft/
  hiprand/
  hipsolver/
  hipsparse/
  hipsparselt/
  hiptensor/
  miopen/
  rocblas/
  rocfft/
  rocprim/
  rocrand/
  rocsolver/
  rocsparse/
  rocthrust/
  rocwmma/
  rpp/
shared/
  rocroller/
  tensile/
  mxdatagenerator/
  origami/

The repository root carries more than that. Alongside .clang-format, .cmake-format.py, CMakeLists.txt, CMakePresets.json, CONTRIBUTING.md, README.md, codecov.yml, and .github/, the top level also holds .dvc/, .dvcignore, .gitmodules, .pre-commit-config.yaml, cmake/, dnn-providers/, docs/, skills/, test/, and tools/. None of those names appear in the structure listing, and no section explains what they are for. The presence of .gitmodules sits oddly beside a plain directory tree for a super-repo described as consolidating libraries into a single repository, with folders that correspond one to one to libraries formerly kept standalone. Whether projects/ entries are real directories or checkouts of other repositories is not stated. The license note has to cover all of it with one sentence about files outside projects/ and shared/, which means a file sitting in dnn-providers/ or test/ is governed by a header notice rather than by any directory-level license file.

Badge hosts, job paths, and one empty cell

Every migration row carries a legacy CI badge except composablekernel, whose status cell is empty. The badges are not uniform either. Most rows point at math-ci.amd.com under a job path beginning rocm-libraries and job precheckin. The miopen row points somewhere else: micimaster.amd.com, on a path reading rocm-libraries-folder rather than rocm-libraries, with the job named MIOpen in mixed case while its neighbours use lowercase names. The rpp row also leaves the pattern, using a job path of precheckin-cv-nightly-therock instead of plain precheckin. hipblaslt is the only row carrying two badges at once, one on precheckin and one on preliminary. A separate pair of badges at the top of the file covers TheRock CI running on the develop branch, for both push and nightly events. Every legacy badge is a lastBuild link into an external build server, not a pass or fail record kept in the repository, and every one is written as a plain http:// URL.

Source of truth for code, old repository for releases

The Completed definition carries a tension worth reading twice. It says this super-repo should be considered the source of truth for the project, then adds that the old repository may still be used for certain release activities. The answer to where the code lives and the answer to where a release comes from can therefore point at two different places at the same time. What is not specified is which release activities. Tagging, artifact publishing, version numbering, and branch management are all candidates and none of them is named. The In Progress definition has the same shape, telling contributors to refrain from submitting pull requests on an individual repository and to develop on the super-repo, so someone following both definitions correctly still cannot tell whether a version tag belongs here or in the old repository. The default branch is develop, and the most recent push landed on 1 October 2026.

Four shared folders ship no package of their own

The second half of the structure listing explains why four components sit under shared/ instead of projects/: code that used to live in its own repository, is used as a dependency by several libraries, and did not produce distinct packages in earlier ROCm releases. That description covers rocroller, tensile, mxdatagenerator, and origami. The consequences run past the directory layout. A consumer looking for a package named after one of those four will not find one in previous releases, so an install plan built around package names has to reach through the libraries that depend on them. And a license question asked at the package level has no answer for them, since there is no package whose terms can be read. The projects/ definition makes the same kind of claim about packaging history rather than about maturity. The table lists all four shared/ components as Completed with legacy CI badges, so the split between the two folders is decided by release shape, not by whether migration finished.

No build command, only a link to CONTRIBUTING.md

Getting Started is one sentence long and it points elsewhere: contributors and builders are sent to CONTRIBUTING.md for setup instructions, sparse-checkout configuration, development workflow, and pull request guidelines. No configure line, no build command, no install step, and no hardware or driver requirement appears in this repository's own text. That is a defensible choice for a super-repo of this size, since the right answer differs per component, but it does mean the README tells you almost nothing about what it takes to build any given library. The root does show the build stack: CMakeLists.txt and CMakePresets.json at the top, a cmake/ directory, .clang-format for C++ and .cmake-format.py for CMake files, .pre-commit-config.yaml for hook automation, and codecov.yml for coverage reporting. The sparse-checkout mention is the closest hint to how anyone actually works here, since it implies checking out one component rather than the whole tree. Two facts recorded outside the README set the tone: the primary language is given as Assembly, and the license field carries no value.

Release tags carry TheRock names and two live version lines

Three recent releases are visible, and none of them is named after a library: therock-7.14 on 15 July 2026, therock-10.0 on 26 August 2026, and therock-7.14.1 on 31 August 2026. The naming comes from TheRock, the separate build system this super-repo's CI runs on. Two things follow from that. First, the tags do not carry the version of any component inside projects/, so a component's own version cannot be read off a release here, and the visible tag list contains no per component release at all. Second, the 7.14 line and the 10.0 line are both current, and the two August releases are five days apart, so the repository is shipping two version lines at once. Choosing which line to install is a decision that the tag list alone does not settle.

Standardized names break anything written against the old repos

A short Nomenclature section states that project names have been standardized to match the casing and punctuation of released packages, removing inconsistent camel-casing and underscores used in legacy repositories. The directory names make the point: hipblaslt, rocsolver, and mxdatagenerator are spelled the way the packages are, which is not how every one of the old repositories spelled itself. For a human reader this is a small cleanup. For anything automated it is a breaking change, because a path, a CMake target, a CI job name, or a grep pattern written against the previous spelling stops matching the moment a directory is renamed. Nothing here says whether the old names survive as aliases or redirects. Set that beside the rule that each subproject keeps the license it was originally published under, and a rename also raises the question of which directory's license file applies to a component that has moved from an old repository into this tree.

Editorial conclusion

Treat the migration table as a claim to verify rather than a guarantee. If you are picking a component to work on, check that the directory you want actually has a row, read the badge host before trusting a green link, and read the license file inside the component folder before building on it. Pull requests for everything marked Completed belong here on the develop branch; version tags and package-level questions are a different matter, because the old standalone repositories may still own release activity.

Frequently asked questions

Official sources

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