I wanted to bump this thread started by @peci1 over to a longer term visible platform. As I think it’s an important discussion to have. Quoting from the Release Chat below. @nuclearsandwich @Yadunund
I would actually advocate for the position that sync freezes be approximately periodic, but not be pre-announced by a small margin to allow last minute releases.
In my experience the primary reason that maintainers like the pre-announcement is that they want to slip in a release right before the sync. This hurts the system in multiple ways. First it will potentially break the ability of the ROS release manager from being able to consider evaluating the status of the buildfarm for sync for potentially a day while the buildfarm is rebuilding the potential releases. Furthermore if there is a regression in one of those last minute changes, it can require a revert and other operations during the sync freeze period. The other approach is that the release maintainer is reviewing the status of testing continuously and in the sync window they decide that it’s reached a good enough state to think about releasing. In some cases if there’s still several releases ongoing the release manager can declare the freeze while things are in process and wait and triage the results only after things stablize during the freeze. But in general this will require us to have the freeze be longer.
THe second reason for not pre-announcing the syncs is that it incentivizes last minute releases right before the sync. And this completely defeats the purpose of the testing repository. We want content in the testing repository for as long as possible before it gets pushed to the main repository. This allows us to let both our automated tools as well as potentially manual testing happen before we push the content out to everyone. If maintainers make a habit of releasing just before the sync our odds of major regressions will go up significantly.
An alternative that I’ve thought about quite a lot would be to do a much more purely time based one with a signficant testing period. Such as after each release there’s a merge window (say a week) and then an equivalent freeze window for testing. And then the releases end up on a nice biweekly release cadence. It could be monthly, with 2 weeks for each part etc. But I think that gets a little bit too rigid and if there’s an issue to be debugged, you either need to catch up or delay the next release cycle.
Overall I think it’s valuable to have a regular cadence. But I would like to encourage maintainers to release early in the cycle instead of waiting to the last minute. And in particular if there’s something urgent that needs to be taken care of it, should have already been merged/discussed/talked about with the release manager prior to them announcing the sync. Otherwise the release seems like it could wait for the next sync.
Yadunund3:52 am
Hi all,
Please hold rosdistro PRs for iron AFTER the end of this Tuesday (pacific time). This is to give folks some time between the announcement and freeze. I’ll aim to do a sync on Friday.
Announcement: Preparing for Iron Sync 2023-06-16
1
peci14:40 am
@Yadunund I really like your approach, instead of the “out-of-the-blue freezes”
nuclearsandwich7:25 pm
@peci1 this is the same workflow that all ROS bosses strive for. It can be challenging to maintain unflinchingly as a distribution ages and releases have an increased likelihood of introducing regressions which then need to be walked back. I appreciate the positive message for Yadu but appreciate less the implicit shot taken at other ROS bosses in absence of a request for the change you’d actually like to see.
In general, the approach I recommend for package maintainers is to release changes as soon as they are ready in order to give them time in the
testingrepository and be picked up in the next sync whenever that is.
1
quarkytale10:44 pm
Ironic to announce it, but this wasn’t totally out-of-the-blue, sync hold for the final release for Foxy starting this week. Preparing for final Foxy sync and patch release 2023-06-12
(edited)
peci111:39 pm
@nuclearsandwich Oh, I didn’t want my remark to sound as a pun to other release maintainers. I just wanted to give a
Today
nuclearsandwich6:53 am
I think there’s a balance between declaring the intent early and being able to confidently meet the commitment implied in that announcement which has caused a number of us to skew towards syncing whenever things are good enough to sync. I have certainly done so, especially when a sync has been delayed. So I think rather than having it be something that’s not yet common, I think it’s something that’s fallen out of norm.
