Indeed as a release manager I generally prefer not to to have a rush of releases right before the sync. It gives the highest likelyhood of regressions. The longer since something has been released the more likely someone will have caught a regression.
There is not a lot of manual testing. However all the PR builds and devel job builds are run against the testing repositories. This means that any package that has a commit or a PR submitted will be tested against the new release. In addition if there has been enough time to complete a rebuild then it’s at least clear that all downstream packages at least build.
If there’s a flurry of releases just before the freeze then a large fraction of the freeze will be spent with the farm just rebuilding and it will require urgent fixes during the closing freeze window which might even be blocking others from testing. We can only get a few iterations of rebuilds in during a sync window. So if there’s multiple things to triage that interfere it’s possible that one regression prevents the testing or debugging of another package entirely. Whereas if we’re in an already validated good state with no issues we only have to deal with the unusual regressions.
We are working to keep the syncs on a regular cadence. And that should allow maintainers to batch up changes in their preferred manner.
Also note that rolling back in the testing repository is possible. Once it’s been deployed to the the main repository any regression that requires a rollback then requires a new higher numbered release with the changes reverted and an extra sync to distribute it generally. The freeze is considered the minimum testing time and generally for core packages we will often hold packages even before a freeze and land them at the beginning of a testing cycle to make sure that they get as much soak time in the testing repository as possible. If users can’t wait for an extra sync cycle to get the latest fixes/features I generally recommend that they use the testing repository anyway as they are preferring the speed over the stability. Trying to game the system and have the minimum testing time has the tradeoff of increasing the risks of regressions for everyone and makes the main repository users experience more like the testing repository user’s experience.