I was wondering whether it could be doable and desirable to make all ROS 2 syncs taking place at the same time. Currently, Foxy, Humble and Rolling syncs take place at different times and this can lead to some overhead for package maintainers.
Let me explain.
As far as we are concerned with the webots_ros2 package, we host all versions (Foxy, Humble and Rolling) on the same branch (main) by using compile-time defines to handle the API differences between ROS versions. This is very convenient and efficient.
We are also maintaining a Webots tutorial on the ROS 2 documentation web site for which we support all the currently supported ROS 2 versions. Again the source code for this tutorial is hosted on a single branch, but in that case, it is harder to handle nicely the differences between the versions as there is no powerful define mechanism to help with that.
Because our webots_ros2 package evolves, we need to update the tutorial and if the different releases are synchronized at different time, this means we have to push the updated tutorials at different times as well, so that the published tutorial for a specific version matches the currently released version. This is pretty tedious and error prone.
If the syncs for Foxy/Humble/Rolling/etc. would take place at the same time, we could also push the updated tutorial at the same time on all the branches of the documentation which would greatly simplify our lives.
Therefore my question: Why don’t we synchronize the syncs?
At Foxglove, we also maintain some packages (e.g. foxglove_bridge, foxglove_msgs) which use a single development branch to support all distros — even ROS 1 & ROS 2. More aligned & more frequent syncs would be greatly appreciated.
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)
To answer your last question, I would say that the problem is similar to what we are doing with the Webots software for which the same version or revision is released simultaneously on different platforms (Linux, Windows and macOS). Before releasing, if we detect that one of the three packages has a regression, we postpone the release of the three packages until the regression is fixed. Similarly, for our webots_ros2 package, if we detect that it has a regression on Foxy, we would be happy to revert it in all distributions until the regression in Foxy is fixed.
I believe that if some user want to be on the bleeding edge and use the latest version of our ROS package, they can always compile it from the source (which is a process that we document thoroughly). If they choose to use the stable version, they would have the guarantee that it is the very same version on all the ROS 2 distributions and the official documentation matches this version. This would save users from all the problems related to version mismatch like: “I don’t understand, it doesn’t work same in Foxy and Humble” or “The documentation looks wrong”, or “Unfortunately, this version of the package is not available on Foxy yet, but it is available on Humble, thus I cannot install this dependency.”, etc. I believe this would simplifies the lives of users, in addition to simplifying the lives of packages maintainers and the lives of technical support teams.
I would like to hear the voice of some other ROS package maintainers here to understand if this model could also satisfy them or if they would prefer asynchronous releases of their packages, and why.