ROOT

All sampled first-parent commits in 12 months came through PRs, master is protected, CODEOWNERS and a PR template exist, and CONTRIBUTING describes review; 89.9% of merged PRs had a non-author review, just below the 90% required for level 3.

Gaps to the next level

• 10.1% of merged PRs in 12 months had no review from someone other than the author.
• The public rulesets require a PR and review only on v*-patches branches (with 0 required approvals), not on master.

Actions

• medium S Add a ruleset on master requiring one approving review (CODEOWNERS review where an owner exists).

ROOT CI builds and runs ctest on about 27 configurations on every PR and master push, but of the 50 push runs in the metric only 2 of 43 ROOT CI runs passed every job and all 7 Sync Cling repo runs failed at checkout. Failing ROOT CI runs have 1 to 7 of 27 jobs failing, mostly new or pre-release platforms: ubuntu2610 in 29 of 43 (a distributed-RDataFrame test timeout, issue 23675), fedora44 in 20, and mac27 and mac-beta in 12 each.

Gaps to the next level

• 4% of recent default-branch runs succeed; ROOT CI on master fails in 41 of 43 recent push runs.
• Sync Cling repo has failed on all 7 recent master pushes at the "Checkout Cling" step.
• No required status checks on master (branch protection lists none).

Actions

• high M Mark the ubuntu2610, fedora44, mac27 and mac-beta jobs as non-blocking (or fix issue 23675 and the platform failures) so ROOT CI on master passes.
• high S Fix the CLING_GIT_TOKEN checkout in .github/workflows/sync_cling.yml or disable the workflow.

1555 test files (GoogleTest unit tests per module, pytest, and roottest with 1029 .ref reference-output files) run through ctest in CI on every PR, tutorials run as tests, and coverage is uploaded nightly to Codecov (60.9% of lines). 40.7% of merged PRs in 12 months touched tests.

clang-format, clang-tidy (WarningsAsErrors: '*') and ruff check every PR, the debian13 CI job builds with dev=ON (-Werror), and an ASan build runs in the CI matrix. Global flags disable only two specific warnings.

The code is split into libraries (core, io, tree, hist, math, roofit, ...) with inc/ and src/ separation, builds with CMake 3.20 and C++17/20/23, and exports ROOTConfig.cmake; the architecture page documents the components. Libraries are not usable independently of Core and the Cling interpreter, and components share global state (gROOT, gDirectory, gPad, gStyle).

Gaps to the next level

• Every library depends on Core and Cling at runtime, so components cannot be reused independently.
• Components communicate through documented global variables (gROOT, gDirectory, gPad).

Actions

• low M Document which libraries can be linked without Cling (for example the RNTuple and histogram v7 libraries) and test such a minimal consumer in CI.

root.cern documents installation through binaries, conda, Spack-based LCG views, distribution packages and from source, lists all build options, and has a getting-started guide, a manual and tutorials that run as ctest tests; reference docs are versioned per release. Required libraries are listed per distribution without minimum versions (only compilers and C++ standard), and there is no FAQ or troubleshooting page.

Gaps to the next level

• The dependencies page gives no minimum versions for required libraries (only compilers and C++ standard).
• No FAQ or troubleshooting page; users are referred to the forum.

Actions

• medium S Add minimum versions for each required library to https://root.cern/install/dependencies/ (matching SearchInstalledSoftware.cmake).
• medium S Add a troubleshooting page for common build and runtime errors to the manual.

The Doxygen reference guide is generated and published to root.cern by the docs CI for master and each release branch, the manual covers architecture and each functional area, and design documents exist in-tree (for example RNTuple architecture and binary format). Algorithm documentation cites references in the reference guide (for example Minuit2, RooFit, TMVA).

CONTRIBUTING.md covers build and test links, coding conventions, commit and PR format, tests and the CI checks, with PR and issue templates; 89 issues carry good first issue, and some were closed by first-time contributors. No ready-made development environment (devcontainer or documented CI image) is described.

Gaps to the next level

• No devcontainer or documented container image for development, although CI images exist (root-ci-images).

Actions

• medium S Document building and testing ROOT inside the public registry.cern.ch/root-ci/<os>:buildready images, or add .devcontainer/devcontainer.json based on one.

Median first response is 0.68 days and 97.7% of new issues are labeled, but 282 of 380 open issues (74%) are older than one year, which is more than half.

Gaps to the next level

• 74% of open issues are older than one year.

Actions

• medium M Review the 282 issues open longer than one year and close, or label and milestone, each one.

173 authors in 24 months from 34 e-mail domains, 58 new authors in 12 months, and 55.5% of merged PRs from contributors outside the maintainer group.

Bus factor (50%) is 5, 22 people reviewed and 18 merged in 12 months, CODEOWNERS names two owners for most directories, and the team spans CERN, Fermilab and GSI. Some components have a single owner (/geom/, /tmva/, /net/http/, /cmake/), and all releases in 24 months were published by one account.

Gaps to the next level

• Single CODEOWNERS entries for /geom/, /tmva/, /net/http/, the web GUI directories and /cmake/.
• Releases published by one account in 24 months; the release procedure is not publicly documented.

Actions

• medium S Add a second owner to each single-owner path in .github/CODEOWNERS.
• medium S Document the release procedure (tagging, root-src-tarball.yml, root-relpage-ci.yml, binaries) in README/DEVELOPMENT.md.

The project leader and team are named, the yearly Program of Work process and weekly developer meetings are public, and milestones exist up to 7.00; there is no documented decision process or path to becoming a reviewer or maintainer.

Gaps to the next level

• No document states who makes decisions or how a contributor becomes a reviewer or maintainer.
• The latest Program of Work listed is for 2025.

Actions

• high S Add a GOVERNANCE.md naming the project leader and core team, how decisions are made, and how contributors become reviewers or code owners.

The README links the ROOT Forum, which is active, and the issue tracker; no code of conduct with a reporting contact applies to the repository or organization (the forum carries only generic Discourse guidelines).

Gaps to the next level

• No code of conduct with a reporting contact.

Actions

• high S Add CODE_OF_CONDUCT.md (Contributor Covenant or the CERN Code of Conduct) with a reporting contact, and link it from the README.

ROOT 6.40.04, the latest feature-series release (2026-08-27), is in upstream Spack and ships in eic-shell, where it was pinned two days after release; conda-forge also provides 6.40.04. The collector's latest_tag (v6-36-14) is a later-dated patch release of an older series, so latest_release_packaged = false does not indicate lag.

40 releases in 24 months with notes, a documented MAJOR.MINOR.PATCH scheme with even/odd stable and development series and compatibility guarantees, per-version release notes with Deprecations and Removals sections that name the removal release and replacement, and workflows that build source tarballs, binaries and release pages.

Dependencies are declared in SearchInstalledSoftware.cmake with builtin fallbacks pinned by version and hash, but many required packages have no minimum version (LZ4, LibLZMA, ZLIB, xxHash, Freetype, XRootD, OpenSSL, ...). There is a SECURITY.md, but no Dependabot or Renovate, and 72 action references are not pinned to a SHA.

Gaps to the next level

• Most ROOT_FIND_REQUIRED_DEP calls give no minimum version.
• No automated update monitoring for dependencies or GitHub Actions.

Actions

• medium M Add the minimum supported version to every ROOT_FIND_REQUIRED_DEP and find_package call in cmake/modules/SearchInstalledSoftware.cmake.
• low S Add .github/dependabot.yml for github-actions.

Release-tagged Docker images (rootproject/root:<version>-<os>) are documented on the install page, CI uses public versioned build images, and ROOT files record the writing ROOT version and class schemas. The Docker images are not published for 6.40 (latest tag 6.38.00), and CI does not run in the published user images.

Gaps to the next level

• No Docker image for the 6.40 releases; images are not built for every release.
• CI runs in root-ci build images, not in the published release images.

Actions

• medium M Publish rootproject/root:<version>-<os> images from a workflow triggered by each release tag.

CI builds and tests on 12 Linux distribution versions (GCC and Clang, x86_64 and aarch64), macOS ARM64 and x86_64, and Windows; ROOT is distributed on CVMFS through LCG views and runs on grid and batch resources; CUDA support exists as build options, although the GPU CI job is disabled.

ROOT is a base component that needs no other EIC-supported domain functionality and uses the external Pythia8 and XRootD packages rather than copies; 25 eic-spack packages (including podio-based EDM4eic, JANA2, EICrecon and npsim) build on it.

ROOT defines the TTree and RNTuple file formats used by podio for EDM4hep and EDM4eic files; the RNTuple binary format has a versioned specification, files carry format and class versions checked on read, I/O tests cover round trips, and uproot reads the files without ROOT.

ROOT is built in eic-shell from a pinned version in eic/containers, whose CI builds the image and runs EICrecon simulation and reconstruction jobs every six hours and on PRs. ROOT development versions or release candidates are not built or tested in an eic container before release.

Gaps to the next level

• No CI tests ROOT master or a release candidate in an eic container image.

Actions

• medium M (EIC side) Add an eic/containers job that builds the eic_xl environment with the next ROOT release candidate and runs the EICrecon tests.

eic-shell ships the latest ROOT release; 6.40.04 was pinned in eic/containers two days after its release, and issues reported from the EIC stack (for example an RNTuple data race found with podio and JANA2) were fixed. ROOT uses only generic EIC-stack components (XRootD, Pythia8) and keeps a compatibility workaround for XRootD older than 5.8.4.

ROOT is LGPL-2.1-or-later, but LICENSE is a notice with the text in LGPL2_1.txt, so GitHub reports NOASSERTION; MathMore is GPL-only and RooFit has a BSD-style license, and source files carry no SPDX headers.

Gaps to the next level

• The license is not machine-detectable (SPDX NOASSERTION).
• Licensing differs across components (LGPL, GPL for MathMore, BSD-style for RooFit) without per-file SPDX identifiers.

Actions

• high S Put the full LGPL-2.1 text in LICENSE (moving the notice to the README) so GitHub detects LGPL-2.1-or-later, and add LICENSES/ entries for GPL and RooFit parts.

The Zenodo-GitHub integration gives every release a DOI under concept DOI 10.5281/zenodo.848818, the README gives the reference paper and BibTeX, and README/CREDITS lists contributors. CREDITS was last updated in 2023 although 58 authors were new in 12 months, and the README does not mention the DOI.

Gaps to the next level

• README/CREDITS has not been updated since 2023; recent contributors are not credited.
• No CITATION.cff, and the README does not cite the software DOI.

Actions

• medium S Add CITATION.cff with the concept DOI and the reference paper, and update README/CREDITS at each release.

ROOT ships in eic-shell and is a dependency of 25 eic-spack packages, including the ePIC production chain (EDM4eic, JANA2, EICrecon, npsim), and is used by experiments outside EIC.

The team page lists maintainers at CERN, Fermilab and GSI, and the Program of Work page states that the yearly plan is presented at the CERN EP-SFT group and agreed with experiments and funders. No document states a multi-institution maintenance commitment or a succession plan.

Gaps to the next level

• No documented multi-institution maintenance commitment or succession plan.

Actions

• low S Document on root.cern the institutions committed to maintenance, their areas, and how ownership transfers when a team member leaves.