The quick fix would be to change the repository base URL in the CDash project settings to MITK but I guess the preferred solution may be something like a setting in the MITK CDash script to decide if MITK should be the repository of interest or an MITK extension should be the repository of interest. Thinking about it, it probably must be a combination of CDash project settings and CDash script as we cannot change project settings from script but probably we can somehow achieve to report a revision from another repository than MITK in the update step.

I'm currently in develop branch (0d336d68).
What I meant to say is that, from what I see in QmitkMeasurementView, the crosshair navigation should be limited when placing a figure. However, the method QmitkMeasurementView::DisableCrosshairNavigation() fails to load the limited display interactor.

I landed the changes of D423. For the next steps, consider T27507#211912.

I landed the changes of D424. For the next steps, consider T27507#211912.

We had a discussion about refactoring the segmentation tools (similar to {D380}). The idea is to outsource redundant code into base classes (e.g. time-management, slice extraction, input data checks etc.) to have a single point of truth for the starting point of the different segmentation-tool-algorithms. This would make the tools less error prone and can simplify testing (even allow automatic testing for the input management steps) (see T27800#211467).

OpenCV 3.4.11 (https://opencv.org/releases/)

Trivial should be:

Known issue: https://github.com/rstudio/rstudio/issues/4718

Fix! :-)

PS: as an explanation, one theory is that the install-zip-package still references libraries from the build machine which causes the different behaviour

In T27669#211004, @schererj wrote:

@nolden I tried the "make package" and it went through without any issues.
Should I upload the result here? Or is it just about the information that there are no error?
Could you please explain what you mean with "target machine"?

I looked again at the tests we have inside the checklist and I think it is still very long and many steps are redundant - because only the clicked tool-button changes and the underlying segmentation algorithm produces different results.
I think it is clearer and even better for testing a specific tool / algorithm, if we somehow separate the tests for different tools.
Also,

In T27507#211660, @thomass wrote:

If necessary, I might need a helping hand because static/dynamic*single/double*2DTools/3DTools = many test cases

Another solution is to use a numeric input field that does not accept other characters.

Deleted branch bugfix/T25882-RewriteDashboardScript.

Deleted branch feature/T25882-MITKOptions.

Pushed new branch feature/T25882-MITKOptions.

Open problems will be tackled in subtasks of T27807: [MultiLabel Segmentation] Inspection of module and plugin, e.g. T27809 and T27810.

This was a tricky bug, thanks!
alpha is now respected, argument FUN is removed. significance ranking is considered an aggregation step, so testThenRank() is nothing else than aggregateThenRank(FUN="significance").
Note that testThenRank will pass all arguments to decision.challenge(), i.e. it will respect arguments: