2025.12.16Weekly Meeting

Community Weekly meetings
1

Tomorrow, we will be having our next weekly hangout at 11:00 AM ET until 12:00 PM ET. after the project week meetings. We will be re-using the same meeting link

Anyone is welcome to join at this link: Launch Meeting - Zoom

Agenda:

Please post to this thread to put a topic on the agenda! We will try to prioritize agenda items during the meeting.

Thanks
Sam and Ebrahim

2

Slicer Meeting Notes Dec 16 2025

2D transform read support (Dzenan)

PR 8842 is ready to be reviewed. The commits will be re-grouped into 2-3 commits to make this easier to review, and a timing test will be added:

It is not clear whether transform reading performance will be impacted by some of the 2D vs 3D checks. It is worth testing whether the transform read time is impacted when trying to read a dense 3D displacement field.

Subject hierarchy node thing (Andras)

  • could be parameter node related
  • Sam will look into it

Telemetry extension (Bernardo)

  • It is recommended to test against and target 5.10 since that is stable, and nightly is going to become less stable with Qt6 coming.
  • Next thing to do is for Bernie to open an issue on the SlicerTelemetry repo describing all the details about how to set up a server.

Containers (Ruffin)

  • waiting on Qt6
  • can container spawn on distrobox?
    • those dev containers are configured in a way that does a lot of what distrobox automates

ways to rebuild more quickly/incrementally (Ruffin)

  • The ccache tip in the build docs
  • Remaking from the superbuild level often does a lot of work for small changes, due to a not yet understood issue in the VTK cmake system. If you know exactly what changed and you only need to rebuild a certain library you can cd into it and make from there
  • Remaking from the inner build (Slicer-build/) is not too bad-- that is usually pretty fast and clean.

superbuild cloning doesn’t need history (Steve)

Do we really need to git clone the entire project histories in our superbuild (for VTK, etc.)? We should consider adding --depth 1 to our clone commands.

Maybe there was a reason we haven’t been doing that already – it would be good to hear people’s thoughts.

Qt6 (all)

PRs to review

Issues

Discussion on correct logic/widget breakdown on SlicerNNUnet/SlicerDentalSegmentator (Mauro)

Notes: Slicer Meeting Notes Dec 16 2025 - HackMD

1 Like
3

@pieper According to the CMake documentation for ExternalProject git usage, shallow depth cloning is not supported as we use commit hashes for our external projects. See relevant CMake documentation snippets below:

  • Using a specific git hash ensures that the main project’s own history is fully traceable to a specific point in the external project’s evolution. If a branch or tag name is used instead, then checking out a specific commit of the main project doesn’t necessarily pin the whole build to a specific point in the life of the external project. The lack of such deterministic behavior makes the main project lose traceability and repeatability.

If GIT_SHALLOW is enabled then GIT_TAG works only with branch names and tags. A commit hash is not allowed.

GIT_SHALLOW <bool>

Added in version 3.6.

When this option is enabled, the git clone operation will be given the --depth 1 option. This performs a shallow clone, which avoids downloading the whole history and instead retrieves just the commit denoted by the GIT_TAG option.

1 Like