That’s strange they are not highlighted by the CI. Shall I stop the vote the process a RC2?
It is up to you. These are only minor checkstyle errors. I noticed them using the Eclipse checkstyle plugin, maybe it uses a more recent checkstyle version than our pom.xml? (Eclipse version: 2023-09, Eclipse Checkstyle plugin 10.10.0.202309291129).
It does not show on SonarQube neither, where the plugin version is 4.27, which corresponds to Checkstyle v8.27.
My current feeling is to follow the CI and Sonar: if they don’t triggered any warning or error, let the vote continue.
My only comcern is about the error highlighted by @hankgrabowski. I unfortunately can’t reproduce it since everything is ok on my laptops and the CI. It looks to be specific to Apple computer. If it shall be fixed for the release, so a RC-2 will be done including the UML fix and the Javadoc fixes
I am looking at this today. I will keep you posted. I did an OS upgrade to Sonoma yesterday so actually starting with a clean slate attempt. If that still fails I will try your JUnit suggestion.
Update: I tried JUnit 5.9.0 against the latest Azul build of OpenJDK 8, 17, and 21. All of them failed in the same way :(.
I’m going to try playing with some other settings…
Thank you very much @hankgrabowski for taking care of that. Your help is very helpful since the problem looks very specific to an OS 
+1 for the release!
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.
+1 from me.
Thank you very much @hankgrabowski for the fix!
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.
I’ll propose the RC2 this evening.
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.
Yes, could you open a merge request with release-12.0 a target branch?
I opened MR 445
I don’t understand why it references #1250 in the overview. I checked the commit message, it was OK.
Well, it seems my MR includes all the previous commits from myself and Sébastien, but not the commit for #1256. I’ll update the MR
Great! Thank you
I close the vote since I’ll proceed a RC2 this evening.
200 issues reached for the 12.0 milestone 
3 Likes
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.