Geant4

The GitHub mirror (and the public gitlab.cern.ch/geant4/geant4) contains only "Import Geant4 X source tree" commits by one author; development and merge-request review happen in the private geant4-dev GitLab project, so no change history or review is publicly visible.

Gaps to the next level

• The repository that receives the actual changes (geant4-dev) and its merge requests are not publicly readable.
• GitHub pull requests are closed and re-applied in the private repository, so their review is not visible.

Actions

• high M Make geant4-dev (or a read-only mirror carrying per-merge-request history) publicly readable, so merged changes and their approvals can be inspected.

No public CI: the mirror has no workflows, GitLab pipelines return 403, and the CDash dashboard named in the public development procedures requires a CERN login; the stated continuous and nightly testing cannot be verified.

Gaps to the next level

• Continuous and nightly test results are behind CERN single sign-on.
• No build or test runs on the public repositories.

Actions

• high S Make the Geant4 CDash project (cdash-sft.web.cern.ch, project Geant4) publicly readable, or publish nightly results for each release branch.
• high M Add a GitHub Actions workflow on the mirror that builds each imported release and runs ctest on the basic examples on Linux and macOS.

280 example reference outputs (*.out) ship with the source, but the unit and system test tree (tests/) is excluded from the public release and its runs are not publicly visible.

Gaps to the next level

• The tests/ tree (unit, integration and verification tests) is not in the public source.
• No public test runs, coverage measurement, or regression comparison results.

Actions

• medium M Publish the tests/ tree (at least ctests_examples and ctests_integration) with each release so GEANT4_ENABLE_TESTING=ON works on public sources.

.clang-format and a .clang-tidy check set are in the tree and GCC/Clang builds default to -W -Wall -pedantic -Wshadow, but no public CI or pre-commit enforces formatting or analysis; History entries show clang-tidy fixes applied by hand.

Gaps to the next level

• No public evidence that clang-format or clang-tidy is enforced on changes.
• .clang-tidy points to CODING_GUIDELINES.rst, which is not in the public tree.

Actions

• medium S Add a public CI job (or pre-commit.ci on the mirror) that runs clang-format --dry-run --Werror and the .clang-tidy checks on each imported tree, and publish CODING_GUIDELINES.rst.

CMake builds about 140 category modules with C++17/20/23, installs Geant4Config.cmake with Geant4:: targets, keeps run configuration in macros and messengers, and the Toolkit Developer guide documents the category design; only 15 of 142 modules declare private headers.

Gaps to the next level

• 127 of 142 modules install every header as public, so the user API is not separated from internals.

Actions

• medium L Declare internal headers with PRIVATE_HEADERS in each sources.cmake so only the user-facing API is installed.

The hosted, versioned Installation Guide lists compilers, CMake and optional dependencies with versions and documents build options, and example B1 is a runnable quick start, but the only non-source routes are binary tarballs and container recipes; no package-manager or eic-shell route is documented.

Gaps to the next level

• No package-manager route (Spack, conda) is documented, although Geant4 is in upstream Spack.
• Example execution in CI is not publicly visible.

Actions

• medium S Add a "Installing with Spack" section (spack install geant4, with variants for Qt, GDML and datasets) to the Installation Guide.

Public headers carry class descriptions and method comments, a Doxygen reference is published per release, the Toolkit Developer guide describes the category design, and the Physics Reference Manual documents the models with references; publication by CI is not publicly verifiable.

Gaps to the next level

• No public evidence that the Doxygen reference is generated and published automatically.

Actions

• medium S Generate and publish the Doxygen reference from a public CI job for each release (and the development branch).

CONTRIBUTING.rst asks for single-topic GitHub PRs that a responsible person re-applies upstream, with no build, test or convention details; the developer CONTRIBUTING and coding guidelines linked from the website are in the private geant4-dev project.

Gaps to the next level

• No public description of development setup, running tests, or coding conventions.
• No PR or issue templates.

Actions

• medium S Copy the geant4-dev CONTRIBUTING.rst and CODING_GUIDELINES.rst into the public tree, covering build, GEANT4_ENABLE_TESTING, conventions and the PR path.
• low S Add .github/pull_request_template.md asking for the Bugzilla report, affected category and how the change was tested.

GitHub issues are disabled and Bugzilla is the documented tracker: of 102 reports opened in 12 months, 62 had a non-reporter comment (median 3 days) and 18 remain NEW with no comment, and 71 of 115 open reports are older than one year.

Gaps to the next level

• 62% of open Bugzilla reports are older than one year.
• 18 of 102 reports from the last 12 months have no response or assignment.
• Median first maintainer comment on GitHub PRs opened in 12 months is about 13 days.

Actions

• medium M Review the 71 Bugzilla reports opened before October 2025 and close, resolve or re-target each.
• medium S Assign every new Bugzilla report to its category owner within a week and record that rule on the Bug Reports page.

Git metrics show only the importer, but History files name about 60 distinct authors in 24 months (at least 8 first appearing in the last 12) from 142 members at many institutions, and external GitHub PRs are applied upstream; the share of merged changes from outside contributors cannot be measured publicly.

Gaps to the next level

• The fraction of merged changes from contributors outside the collaboration is not publicly measurable.

Actions

• low S Record the origin of each externally contributed change (GitHub PR or Bugzilla number) in the History entry and release notes, so external contributions can be counted.

History files give a 50% bus factor of about 4 (top author about 18% of entries) and CODEOWNERS plus elected coordinators and deputies cover the categories, but one person made every release and import in 24 months and no automated release process is public.

Gaps to the next level

• All releases and source imports in 24 months were made by one person; the release procedure is documented but not automated.
• .github/CODEOWNERS names one owner for /source/processes/hadronic/, /source/analysis/ and /ReleaseNotes/.

Actions

• medium S Have a second named person cut and publish the next patch release and its GitHub import, following the Tag and Release Policy.
• low S Sync .github/CODEOWNERS with .gitlab/CODEOWNERS so every top-level category has two owners.

The website documents the Steering Board, elected working-group coordinators, membership and contributor paths, and public steering-board minutes and a 2026 plan of work are published; ownership is not mapped to any EIC or ePIC structure.

Gaps to the next level

• No mapping of Geant4 ownership or liaison to the EIC or ePIC software organization.

Actions

• low S (EIC side) Name the ePIC contact for Geant4 and record EIC requirements through the Geant4 Technical Forum, linked from the EIC software documentation.

The README documents an active user forum and Bugzilla, but no project code of conduct with a reporting contact was found; the forum's default discussion guidelines only cover flagging posts.

Gaps to the next level

• No code of conduct with a reporting contact applies to the collaboration or its repositories.

Actions

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

Upstream Spack provides 11.4.3 (added eight days after its release), and eic-shell ships Geant4 through eic-spack.

Nine tagged releases in 24 months (a December minor release, a June beta and patches), the major.minor.patch scheme and compatibility rules are documented in the Tag and Release Policy, and each release has notes with a "migration of the user code" section; no automated release process is public.

Gaps to the next level

• No public release automation.
• No written deprecation policy (how long deprecated options and interfaces remain before removal).

Actions

• medium S Add a deprecation section to the Tag and Release Policy stating that deprecated interfaces are announced in release notes and removed only in a major release.

CLHEP, PTL, VecGeom, HDF5, Coin and Qt have minimum versions in CMake, but EXPAT, ZLIB, TBB, XercesC and Freetype have none, and PTL (2.0.0) and VecGeom (1.2.6) minima differ from the 3.0.1 and 2.0.0 stated in the 11.4 release notes.

Gaps to the next level

• find_package for EXPAT, ZLIB, TBB, XercesC and Freetype has no minimum version.
• CMake minima for PTL and VecGeom do not match the documented requirements.

Actions

• medium S Add VERSION arguments to every find_package in G4OptionalComponents.cmake and G4InterfaceOptions.cmake, matching the Installation Guide and release notes.

packaging/rpm holds Dockerfiles and an RPM spec that pin the release and dataset versions, the Installation Guide documents container builds, and random-engine status can be saved per run and event; no versioned images are published and no public CI uses that environment.

Gaps to the next level

• The geant4/geant4 Docker Hub repository is a placeholder last updated in 2022; no image is tagged per release.
• No public CI runs in the release container.

Actions

• medium M Build the packaging/rpm Alma 9 image for each release and push it as geant4/geant4:<version>.

Releases are supported and binary-packaged for Linux/GCC, macOS/Clang (Intel and ARM) and Windows/MSVC, and eic/containers builds and runs Geant4 on amd64 and arm64; Geant4's own test matrix is not public and accelerator support is not documented by the project.

Gaps to the next level

• No public CI from the project for its declared platforms.
• The user documentation does not state the status of GPU offload (AdePT, Celeritas) or why it is not provided in the toolkit.

Actions

• low S Add an Installation Guide or FAQ section describing GPU offload options (G4HepEm, AdePT, Celeritas) and their status.

Geant4 needs little from the EIC stack (Pythia8 for the decayer example; its g4tools ROOT/HDF5 writer is a documented design choice) and is itself the simulation engine reused by DD4hep/DDG4 and npsim; an ePIC geometry fix was contributed upstream.

Geometry I/O uses GDML with published XSD schemas, analysis output goes to ROOT, HDF5 or CSV through G4AnalysisManager and is read with uproot in examples; public round-trip tests and declared output format versions are absent.

Gaps to the next level

• No public GDML or analysis-file round-trip tests.
• Analysis output files carry no Geant4 or format version metadata.

Actions

• medium M Add a public ctest that writes and re-reads a GDML geometry and an ntuple file and compares the results.

eic/containers builds Geant4 into the eic-shell images (default and nightly) every six hours and runs npsim particle-gun and DIS simulations on it on amd64 and arm64; new Geant4 releases and betas are not built or tested in eic-shell before they are adopted.

Gaps to the next level

• Both default and nightly eic-shell builds pin the same Geant4 (11.4.1.east), so new Geant4 versions are not tested against the EIC stack ahead of adoption.

Actions

• medium M (EIC side) Add a scheduled eic/containers job that builds the latest Geant4 patch and beta with the nightly stack and runs the npsim jobs.

Geant4 builds in the current eic-shell with CLHEP 2.4.7.2 (the release-verified version), Qt6 and C++20, but the HepMC examples require HepMC 2.06 and Pythia 6 rather than the shipped HepMC3, and HDF5 2 builds failed until a fix scheduled for 11.5.

Gaps to the next level

• examples/extended/eventgenerator/HepMC uses the HepMC 2 API, not HepMC3.
• eic-shell ships 11.4.1 through an eic fork while 11.4.2 and 11.4.3 are released (EIC side).

Actions

• medium M Port the HepMCEx01, HepMCEx02 and MCTruth examples to HepMC3 and Pythia8.
• medium S (EIC side) Rebase the eAST branch of eic/geant4 onto 11.4.3 and update the eic-spack pin.

The Geant4 Software License 1.0 is a custom license that is not OSI-approved and has no SPDX identifier (GitHub reports NOASSERTION).

Gaps to the next level

• The license is not OSI-approved and not in the SPDX license list.

Actions

• high L Submit the Geant4 Software License to the OSI approval process and the SPDX license list, or relicense under an OSI-approved license.

The README lists three reference papers and CITATION.cff exists, but the file fails validation (the DOI is given as a URL) and lists the collaboration as two partial author entries; there is no software DOI.

Gaps to the next level

• CITATION.cff fails cffconvert --validate (preferred-citation doi must be 10.1016/j.nima.2016.06.125).
• No software DOI.

Actions

• medium S Fix CITATION.cff (bare DOI, single name - Geant4 Collaboration entity author, version and date-released) and validate it with cffconvert.

Geant4 ships in eic-shell and is the simulation engine of npsim, DD4hep/DDG4 and the ePIC simulation campaigns, and it is used by experiments and projects outside EIC.

Maintenance rests on a Collaboration Agreement among laboratories and institutes, 142 members and 47 contributors pledge about 31 FTE for 2026, and coordinators and deputies are elected every two years with a documented spokesperson election process.