I narrowed down the problem to some of the tests not cleaning up their thread pools. So by the time that test came along there were thousands of threads. On Windows the max threads per processes is unlimited. On Linux it is ~30,000. On macOS it is only 4096. I submitted an MR that did the same cleanup across all the various tests that used the ExecutorService thread pool paradigm for multithreading testing. Because the problem was in the test I’d say don’t hold up the release for this if there are no other issues.
I’ll propose a RC2 because even if we don’t deliver the tests, they are important for people using master and release-12.0 branch in the future. I also see that the fix also concerns NtripClient class which is on the main folder.
I’ll include the two documentation fixes of @luc in the RC2. I’ll also include the MR of @sdinot because it will be appreciate for the release process
Finally, I’ll fix #1251 of @MaximeJ because it only concerns the pom.xml file.
Do you think you could also add the patch from Concurrency in LazyLoadedTimeScales?
I can open an issue and do the commit in a few minutes if you want.
I admit to being rusty on the rules of thumb on MRs. Do I merge my own MR once it is approved or does another contributor need to do the merge of an MR under normal circumstances?
Because you are Orekit Developer, we have 100% confidence in your contribution. Therefore, you can merge it. The approval of another Orekit Developer is helpful in case of complex contributions (e.g., big API change, contribution involving a lot of lines changed).
However, for this specific case I prefer handle the merge manually since I will merge it in the release-12.0 branch to process the RC2. It will be merged into develop with the merge of release-12.0 into develop.
