Alexander Alekhin

> parallel/ subdirectory - those details should not be exposed outside of the core module. All modules should use cv::parallel_for_(). Completely wrong assumption. There is API for customized parallel backends....

> `defined(__ARM_NEON) || defined(__aarch64__)` I believe it makes sense to use `defined(__ARM_NEON)` here (to keep support for some "debug" configurations like mentioned `-march=armv8-a+nosimd`)

> pure `defined(__ARM_NEON)` my vote for this (yes, it is not equal to the current conditions)

June 2024 (OpenCV 4.10.0): - docs.opencv.org uses legacy CI builder: https://pullrequest.opencv.org/buildbot/builders/4_x-contrib_docs-lin64/builds/100773 (used version is `EMSDK_VERSION=1.39.0-upstream`) - modern GitHub Actions CI builder is WIP here: https://github.com/opencv/ci-gha-workflow/pull/174

Where is the first line of PR description with the link on related opencv_contrib PR? CI is totally RED.

> `OpenCV samples: Can't find required data file: cv/shared/lena.png in function 'findFile'` You should not use API for "samples" in "tests". Take a look on other tests.

To avoid regressions there is should be proposal for parallel_for in HAL

kmeans and PCA should be moved out of the `core` module first (higher priority than touching of "standalone" ML module)

ML module is a best candidate as target, but it's suggested to be removed.

if we respect OpenCV users then there should a timeframe for transition to avoid unwanted breaking of user code on OpenCV version upgrades. - 4.x: without regressions in default builds...