Thanks for taking the time to write up this feedback and share where it’s coming from.
It took a long time for me to get back onto this issue, mid-December was a busy time.
This did spark some water cooler discussions with a few other members of the ROS team but I will let them speak for themselves in case they’ve also benefited from distilling their thoughts on this over the last several weeks.
I’ll answer the first portion of the question, whether it is doable to make all ROS 2 syncs take place at the same time in the affirmative. There is nothing in the current setup preventing us from running syncs in a swift batch, or even adding a future job which runs all the syncs together.
The second portion, whether it’s desirable, is going to be much harder to answer definitively but I do think that it’s worth examining and I’m glad for this opportunity.
I think that we likely do need to consider Rolling separately from the stable distributions since my eventual goal for Rolling is to reduce or completely eliminate the distinction between testing and main for it entirely and have things land on main as they’re released.
For the stable distributions, a major contributing factor to delays in sync cadence is addressing package regressions. I’m learning to become necessarily brutal in allowing regressions in rolling syncs but for stable releases especially, we try very hard not to drop any packages in a sync. If all stable distributions need to be regression free for a synchronized sync, the amount of effort required to maintain cadence is going to increase further still. One way I could see this model working is if we explicitly close releases more often. When Rolling is totally unblocked it basically works this way: one week of releases, one week of hold pending regressions, sync and repeat. If we got the entire stable set of distros onto the the same free and hold weeks then they would all basically sync together but it also means that 50% of the time new releases are blocked. For the projects that @olivier.michel and @jtbandes mention this might not be an issue as you’d do your releases into every stable distro together during a free week and would wait during hold weeks. But if, for example, one of these packages has a regression in Foxy, do you just revert Foxy (thus mismatching between distributions) or revert the release in all distributions so that you stay in sync?
Would every package maintainer make the same choice? (Not that I think they would need to)