DD4hep

96.5% of first-parent commits arrive through PRs, but only 32.7% of merged PRs carry a review from someone other than the author, below the 50% required for level 2.

Gaps to the next level

• Fewer than 50% of merged PRs have a review by someone other than the author.
• Branch protection requires status checks but no approving review, and there is no CODEOWNERS.

Actions

• high S Require one approving review in the master branch protection rule.
• medium S Add .github/CODEOWNERS assigning each top-level package (DDCore, DDG4, DDDigi, DDRec, ...) to at least one reviewer.

Every PR and push builds and runs ctest for the core and the examples on 8 LCG stacks and the Key4hep nightly, the jobs are required status checks, and 94% of default-branch runs succeed. The macOS job only compiles (without Geant4) and runs no tests, although the manual declares macOS supported.

Gaps to the next level

• The declared macOS platform is built without Geant4 and no tests run on it.
• The run on the assessed commit failed in the required g4units job (6 ddsim tests).

Actions

• medium M Run ctest in .github/workflows/mac.yml with Geant4 enabled (see issue

Unit tests in DDTest and example suites for DDCore, DDG4, DDDigi, DDCond, DDAlign, DDCAD and DDRec run in CI, with ddsim end-to-end runs and regression checks against reference shape meshes and between thread counts. Coverage is not measured and only 1.8% of merged PRs touch test files.

Gaps to the next level

• Test coverage is neither measured nor published (metrics:files.codecov is empty).
• Fewer than 40% of merged PRs touch test files.

Actions

• medium M Add a gcov/lcov build job to .github/workflows/linux.yml and upload results to Codecov.
• medium S Ask in the PR template that bug-fix and feature PRs add or update a ctest.

flake8 runs on every PR for Python, clang-tidy checks only header guards, Coverity runs nightly, and -Wall -Wextra -pedantic are set, but no C++ formatter is configured or enforced.

Gaps to the next level

• No .clang-format and no formatter enforced on C++ code.
• clang-tidy runs only the llvm-header-guard check.

Actions

• high M Add .clang-format and a PR job (or pre-commit.ci) that checks formatting of changed C++ lines.

The code is split into packages (DDCore, DDG4, DDDigi, DDRec, DDCond, DDAlign) with separate include/ and src/ trees, requires C++17, exports a DD4hep:: CMake package, loads detectors as plugins from compact XML, and has per-package user manuals.

The hosted installation page lists minimum versions for CMake, Boost and ROOT and the beginners guide has runnable ddsim and geoDisplay examples, but Geant4, Xerces-C, HepMC3, EDM4hep and LCIO have no versions and the only distribution route is a CentOS 7 LCG_102b view.

Gaps to the next level

• Optional dependencies have no minimum versions, and the documented Boost minimum (1.56) differs from CMake (1.70).
• No Spack, Key4hep or eic-shell installation route is documented.
• The manual's "Build From Source" section reads "NEED REWRITE ONCE FINALIZED".

Actions

• medium S List minimum versions for every optional dependency on the installation page, matching find_package in CMakeLists.txt.
• medium S Add spack install dd4hep, Key4hep and eic-shell routes to the installation page.

Public headers carry Doxygen comments, the Doxygen reference and LaTeX manuals are built and deployed by GitLab CI on master and tags (the hosted reference was generated on the assessed commit's date), and the per-package manuals describe design and data flow with bibliographies.

.github/CONTRIBUTING.md covers the PR and release-notes process and one coding rule, and issue and PR templates exist, but it does not explain environment setup, building or running the tests.

Gaps to the next level

• CONTRIBUTING has no development-environment setup, build or ctest instructions.
• Coding conventions are limited to "no new warnings".

Actions

• medium S Extend .github/CONTRIBUTING.md with an LCG-view or Key4hep setup, the CMake build, ctest, and Python/C++ style rules.

Median first response is 0.32 days, no issue went unanswered and 80% are labeled, but 5 of 13 open issues (38%) are older than one year and only about half of merged PRs show review or comments from someone other than the author.

Gaps to the next level

• 38% of open issues are older than one year (#777,
• The triage process (labels, milestones) is not documented.

Actions

• low S Close or schedule the open issues older than one year, starting with
• medium S Document the label scheme and triage practice in .github/CONTRIBUTING.md.

32 authors in 24 months from 9 e-mail domains, 13 new authors in 12 months, and 23.9% of merged PRs from outside the maintainer group.

Bus factor (50%) is 3, 9 people reviewed and 2 merged, and the website names 4 main developers at CERN and DESY, but there are no per-component owners and all releases in 24 months were cut by one person without a documented procedure.

Gaps to the next level

• No CODEOWNERS or list naming two owners per package.
• Releases are made by one person and the release procedure is not documented.

Actions

• high S Document the tagging and release-notes procedure in RELEASING.md and have a second maintainer tag the next release.
• medium S Add .github/CODEOWNERS with two owners per top-level package.

The main developers are named on the website, but no decision process or maintainer path is documented and the milestones page lists 2019-2020 items only.

Gaps to the next level

• No documented decision process or path to becoming a reviewer or maintainer.
• The roadmap is not kept up to date.

Actions

• medium S Add GOVERNANCE.md naming the maintainers, how decisions are made, and how contributors become maintainers.

Support channels exist (issue tracker with a question template and the dd4hep-developers mailing list), but no code of conduct applies to the repository or the AIDASoft organization.

Gaps to the next level

• No code of conduct with a reporting contact.

Actions

• high S Add CODE_OF_CONDUCT.md (for example the CERN Code of Conduct or Contributor Covenant) with a reporting contact.

Upstream Spack provides 1.38, which is the latest release v01-38 and the version eic-shell ships (the collector's latest_release_packaged = false reflects the v01-38 tag naming).

Nine releases in 24 months each have notes generated from PR descriptions, but the vXX-YY version scheme is not documented anywhere.

Gaps to the next level

• No documented version scheme.
• No flagged breaking changes, deprecation policy, or release workflow.

Actions

• high S State the version scheme (major.minor.patch mapped to vXX-YY[-ZZ] tags) and its compatibility meaning in README.md.

ROOT, Boost, Geant4, EDM4hep and podio have minimum versions, but LCIO, HepMC3, TBB, Xerces-C and G4HepEm do not, and TinyXML 2.5.2 (unmaintained upstream) and a copy of GaudiPluginService are vendored.

Gaps to the next level

• Several find_package calls have no minimum version.
• Unmaintained vendored TinyXML 2.5.2 remains as the default XML parser.

Actions

• medium S Add minimum versions to find_package for LCIO, HepMC3, TBB, XercesC and G4HepEm in CMakeLists.txt.
• medium L Replace the vendored TinyXML 2.5.2 with an external maintained parser (TinyXML2 or Xerces-C as default).

CI runs in pinned LCG views (LCG_101, LCG_106, LCG_107a) and the install page documents sourcing an LCG view; ddsim writes DD4hep and Geant4 versions, all steering parameters and the command line into the run header. No environment is versioned with each DD4hep release.

Gaps to the next level

• Releases do not name a tested environment (LCG or Key4hep release) to reproduce them.

Actions

• medium S State in each release note the LCG and Key4hep stacks the release was tested in.

CI builds and tests with GCC 11/13/15 and Clang 22 on EL9, CentOS 7 and Ubuntu 24.04; macOS is built but not tested, there is no aarch64 job, and accelerator support is not addressed.

Gaps to the next level

• No tests on macOS or aarch64.
• No documentation of batch/HPC use or of why accelerators are not supported.
• Three example scripts contain /afs/ or personal home paths.

Actions

• medium M Add an ubuntu-24.04-arm job and run ctest in the macOS job.

DD4hep builds on ROOT, Geant4, HepMC3 and podio/EDM4hep, its HepMC2 ASCII reader is a documented fallback when HepMC3 is not built, and it is itself the geometry component reused by epic, EICrecon and npsim.

DD4hep defines the compact XML geometry format, reads HepMC3 and EDM4hep and writes EDM4hep, and its EDM4hep outputs are read back in tests by PyROOT. The default .root output uses DD4hep-native classes that need DD4hep dictionaries, and file data-model versions are not checked on read.

Gaps to the next level

• The EDM4hep version of input files is checked only at compile time, not on read.
• The default ddsim .root output cannot be read without DD4hep libraries.

Actions

• medium S Check the EDM4hep schema version from the podio metadata in EDM4hepFileReader.cpp and warn on mismatch.

eic/containers builds DD4hep 1.38 for eic-shell and the epic CI runs DD4hep tools (checkGeometry, npsim) in eic_xl:nightly and a pinned stable release, but both use released DD4hep, so no EIC CI tests DD4hep master before a release (calibrated against podio, ACTS, ROOT and EDM4hep in this pass).

Gaps to the next level

• No EIC CI builds DD4hep master or release candidates in an eic container, so incompatibilities surface only after a release.

Actions

• medium M (EIC side) Add a scheduled eic/containers or epic CI job that builds DD4hep master in eic_ci:nightly and runs the epic geometry checks.

DD4hep 1.38 is the version in current eic-shell and CI tracks ROOT and Geant4 development stacks, but DrawBField.cpp includes ROOT headers Hoption.h/Hparam.h that emit deprecation warnings in the dev3 CI build.

Gaps to the next level

• Uses ROOT headers deprecated for removal in ROOT 6.44.
• Compatibility code for podio < 1.0 and EDM4hep < 1.0 remains.

Actions

• medium S Replace Hoption.h/Hparam.h in DDCore/src/graphics/DrawBField.cpp with the public THistPainter interface.
• low M (EIC side) Add a scheduled eic-shell job that builds DD4hep master and runs the epic geometry checks before each DD4hep release.

LGPL-3.0 is detected and declared in Spack, but the bundled GaudiPluginService is GPL-3.0 with its own LICENCE and is built into the DD4hep libraries, and the user manual states that DD4hep is GPLv3.

Gaps to the next level

• GPL-3.0 code is shipped inside the LGPL-3.0 project.
• The user manual states a different license (GPLv3) than LICENSE (LGPLv3).

Actions

• high M Re-import GaudiPluginService from current Gaudi (Apache-2.0) or obtain relicensing, and update GaudiPluginService/LICENCE.
• high S Correct the license statement in doc/usermanuals/DD4hep/chapters/basics.tex.

A Zenodo concept DOI (10.5281/zenodo.592244) and .zenodo.json exist and release notes credit each PR author, but the last versioned DOI is for v01-25-01 (February 2023) and .zenodo.json was last changed in 2018.

Gaps to the next level

• Releases after v01-25-01 have no Zenodo DOI.
• .zenodo.json lists 4 creators and has not been updated since 2018; no CITATION.cff.

Actions

• medium S Re-enable the Zenodo-GitHub integration so each release gets a DOI, and update .zenodo.json creators.
• medium S Add CITATION.cff citing the software DOI and the reference publication.

DD4hep ships in eic-shell and underlies the ePIC geometry, simulation and reconstruction, and it is used outside EIC, for example by Key4hep detector models and CMS.

The website and .zenodo.json acknowledge AIDA2020 (Horizon 2020 grant 654168) funding and name developers at CERN and DESY, but no current multi-institution maintenance commitment or succession plan is documented.

Gaps to the next level

• The acknowledged grant ended in 2020; no current institutional commitment or succession plan is documented.

Actions

• medium S State the current supporting institutions and the plan for maintainer succession in the README.