OK. also added all my fixes in the tasks changelog

If you have suggestions for a better structure, please feel free to add it to T28130. The checklists were not even existing before and my goal was to overhaul all the (multi-)label segmentation checklists to include 4D-data tests. I also strove for consistency throughout all checklists.
I see that the bold written statement reads as a new test - that could be changed. However, the test right before already dealt with 4D image data (4D Bild als Testdatensatz) so I assumed it was clear that the 3D-data tests were already finished.
I will also think about some rephrasing / different text format.

To be honest, I just did not understand the checklist correctly. If you know the outcome and read the checklists, they are fine. But for me, it was like a new test starting with loading and testing 3D Data again. So I misunderstood the line Bei den folgenden Aktionen stets mehrere Label, auch auf unterschiedlichen Layern testen. as beeing a new test, because it had of kind of title character. And that is why I thought, I would start with a 3d Image again...

In T28000#219224, @floca wrote:

Just to be sure. How is the process of updating this task description. The person who closes a task/fixes a bug also updates the list in the Task description. Correct?

Just to be sure. How is the process of updating this task description. The person who closes a task/fixes a bug also updates the list in the Task description. Correct?

In case of QmitkSegmentationView the preference was even hijacked for something different but the tooltip in the preferences still indicate the originally intended behavior.

The auto-selection preference should work but I think it isn't able anymore to select all other images to hide them as the used predicate was changed to also check the geometry. The predicate used for auto-selection needs to be more general.

Color is fixed with T28211. The other options really do not work or are implemented very sloppy (volume rendering). I will remove them as one can consider them dummy options at the moment.

Cool, one less to thing to worry about. :)

I see your point. The exact task I used is not a duplicate but we discussed this problem with deactivating the tool inside the mentioned task (and you already suggested to fix the checklist). So I get why this task was not found in the first place.

I am not sure if it is realy a dublicate.

That's exactly what I wrote and defined in the checklist. The checklist is correct as it perfectly reflects what's happening in the workbench. This is - as described in the title of the corresponding section - valid for 4D test data.

The other options "Show as volume rendering" and "Enable auto-selection mode" are not working as described. Or I didn't get the description..

Ah it seems I was mistaking, at least the transparent overlay works, the color mismatch remains.

Ah, when changing the Preference of Segmenation, the mask is changed... How can I create a "Multilabel Mask"?

Yes, it is exactly as you described: static -> all timesteps, dynamic -> toolbox to apply to all timesteps or not.

I think it is the checklist. When creating a new segmentation based on a dynamic image you now can decide between a static segmentation that has a single timestep spanning over all reference image timesteps and a dynamic segmentation to have matching timesteps. In the latter case only the current timestep should be affected except the tool is explicitly giving the option to be applied to all timesteps at once. Can you confirm?

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.