Additional comment: the missing library doesn't prevent the Workbench from starting, but some/all DICOM functionality is missing which can be confusing

Ok, I just re-checked: Ubuntu 20.04 still has librwrap installed , so installer works. For Fedora there is no workaround , so either

In T28000#218184, @kalali wrote:

Is there something we should take care of in the future when writing commit messages or writing differential summaries? Or is this something we can not avoid and has to be done when combining everything for the regular changelog?

In T28000#218153, @kislinsk wrote:

I noticed that simply merging all the changelogs section-wise doesn't work out very well and generates an overwhelming document probably noone is going to read. I propose the following for the release changelog:

• Merge the thirdparty dependency update table (simple)
• Focus on feature and bugfix oneliners and reference the original changelog if there is more related information
• Roughly sort them by importance/shinyness
• List references to original changelogs with API-breaking changes but explicitly mark the "big ones" that have migration hints/guides

The change log proposal sounds reasonable to me.

I noticed that simply merging all the changelogs section-wise doesn't work out very well and generates an overwhelming document probably noone is going to read. I propose the following for the release changelog:

Pushed new branch to rMITK MITK: release/T28000-v2021.01.

Pushed new branch to rMPT MITK-ProjectTemplate: release/T28000-v2021.01.

Deleted branch from rMITK MITK: release/T28197-2021-Week-04.

Pushed new branch to rMITK MITK: release/T28197-2021-Week-04.

Fixed with D450

Fixed with T28118 (D450)

Deleted branch from rMITK MITK: bugfix/T28195-UpdateMacOSSupport.

Pushed new branch to rMITK MITK: bugfix/T28195-UpdateMacOSSupport.

Deleted branch from rMITK MITK: feature/T27992-CmdLineAppsInWorkbenchReleaseConfig.

@kalali We postpone it as it is not trivial (see T28192; generated a dedicated task for that) but also not critical. Thanks for pointing it out again. I think you could close this task here.

Pushed new branch to rMITK MITK: feature/T27992-CmdLineAppsInWorkbenchReleaseConfig.

I asked in the general Slack channel for command-line apps in use. It boils down to the file converters in CoreCmdApps. Other mentions are too specific for the WorkbenchRelease configuration and are related to the Classification module. We should consider adding a phenotyping build configuration, though.

I looked through the checklist and updated it to be in line with the already updated checklists (see parent task T28108).
I copied the modified document to E130-Daten\Release\Checklisten\MITK Workbench Release.

Ok, I modified T27498#208164 to update the missing views. I say, for the release we leave the utilities the way they are (your option 1. keep it as is: user has to select manually). We keep an eye on it if this leads to some confusion.
SemanticRelations is not relevant for the release so I'll put this in another task.

Deleted branch from rMITK MITK: bugfix/T28189-FixDoxygenWarnings.

Pushed new branch to rMITK MITK: bugfix/T28189-FixDoxygenWarnings.

I used the snapshot client configurations as baseline and created Jenkins jobs in MITK/Release. I also extended the Git hook to trigger these jobs. Hard to test, though, as I do not want to temporarily push test tags. Fingers crossed.

In T28127#217604, @gaoh wrote:

@floca I might have found a dataset, where even the new number is not enough:
P:\Gao\mitk-testdata\

@floca I might have found a dataset, where even the new number is not enough:
edit:
E130-Personal:\Gao\mitk-testdata\

Hm, interesting... I say we but it under the category experience and close that chapter. If it reoccures we see how to handle it. Thanks for investigating it.

Something strange happened:
I wanted to test some GUI functionality for your open diff but somehow I was not able to load data anymore: Clicking on Open File did not open a window.
Then I removed the DKFZ AppData folder to have a fresh MITK workbench. Now clicking on Open File opened a window but while I was scrolling inside this window to find the desired data, the window stopped working (did not scroll anymore - whole application was frozen).
So I did a Windows restart and opened MITK again. Now I am able to load data again and Voila: The segmentation view now automatically selects the newly added data node (patient image selector).
...
...
Tbh, I have no clue what's going on.

@floca thanks for the report! I added a comment to the dcmqi issue you created.

I'm currently on the latest develop (rMITK15ecdf8d92aa). Only a small set of plugins enabled (datastorageviewertest, (ML)segmentation, imagenavigator).
I'm doing this in Debug mode.

In T27498#217438, @kalali wrote:

I just came across this again:
For me the following happens:

1. I open the MITK workbench
2. open the Segementation View
3. below the image selectors a warning Please select an image is shown
4. both image selectors show a red warning
5. I open an image e.g. US4DCyl.nrrd
6. the warning below the image selectors changes to Select or create a segmentation
7. both image selectors still show a red warning
8. the image is not automatically selected

Need to recheck after T28118: Refactoring of SegTool2D is done.

In T27498#209136, @floca wrote:

Just double checked it. As I said the segmentation and ML segmentation view already use auto select and work as they should.

Deleted branch from rMITK MITK: bugfix/T28173-CMakeWarnings.

Pushed new branch to rMITK MITK: bugfix/T28173-CMakeWarnings.

In T28127#217365, @kislinsk wrote:

It depends. NODE_PREDICATE_GEOMETRY_DEFAULT_CHECK_PRECISION is only for checking in predicates;

As long as nobody has missused it so far, it is just used for that. ;) At least I have introduced it with this purpose and only used it there.

Deleted branch from rMPT MITK-ProjectTemplate: bugfix/T28171-MigrateToCurrentMITKDevelopBranch.

Pushed new branch to rMPT MITK-ProjectTemplate: bugfix/T28171-MigrateToCurrentMITKDevelopBranch.

It depends. NODE_PREDICATE_GEOMETRY_DEFAULT_CHECK_PRECISION is only for checking in predicates; not for constant use throughout MITK while are there calculations after calculations after calculations and so the values would drift away further from the actual truth, right? So for a temporary fix, I'm okay. But we should definitely check what is going on in DCMQI and fix on that side preferably.

In T28127#217306, @kislinsk wrote:

1e-5 should still be conservative enough for the purpose of geometries.

Is your statement also valid for 5e-5? Beause 1e-5 would not be enough in that case.

Deleted branch bugfix/T28164-CopyrightDate.

Pushed new branch bugfix/T28164-CopyrightDate.