ROS PMC Minutes for June 10, 2025

The ROS PMC meeting for this week was on Tuesday. The notes from the meeting are available at ROS PMC weekly meeting agenda

(Note, I know that I’m a few weeks behind on minutes, planning to get the last two weeks updated before end of this week).

PMC Business (June 10th)

  • No formal business
  • Continued discussion of TGC funding proposals:
    • Goal to be shared with PMC by Friday, June 13
    • PMC Discussion Tuesday, June 17th
    • Submission to TGC Friday, June 20th

Ongoing Tasks

ROS Bosses

Agenda Items

  • [@Yadunund] PSA for folks blooming breaking changes into rolling
    • Let’s give the community ample time to process deprecation warnings
    • Make a discourse post announcing the future breaking change and a migration guide for users.
    • Changes made to unblock sync:
      • Reverted geometry2 bump on rosdistro that removes deprecated headers.
      • Reverted src change in ament_cmake that removed ament_target_dependencies and bloomed a new release.
      • Left message_filters as is. Only velodyne_pointcloud package is affected.
    • Long discussion (captured in notes) general conclusions:
      • The ament_target_dependencies removal was actually on a somewhat reasonable schedule (in that it had already been deprecated for the kilted release, so a removal in preparation for the lyrical release would make sense).
      • Similarly, the geometry2 deprecations have been around for some time, so maintainers should have at least had warnings around the usage of these headers in their rolling/kilted packages.
      • Even so, these removals without announcement this close to the kilted release may have been too short-notice for many maintainers. In the future, we should make sure that we are following tick-tock and being more vocal about the deprecations that we intend to pursue. In this case, we will likely leave ament_target_dependencies in for most of this cycle, if not all the way through lyrical, with the expectation that it can be removed June 2026.
      • There may be a mismatch of expectations about the stability of the rolling distribution. Some maintainers want to use it as a place to be able to advance their package API, and some want to keep it completely green all the time. It’s going to be nearly impossible to have both. We should probably publish guidance about when to use rolling and when not to use it, as well as best practices around how to maintain packages that support multiple distros.
  • [@Yadunund] rmw_zenoh
    • Note that we will be blooming new releases for Rolling, Kilted, and Jazzy after the Zenoh 1.4 bump. There will be a special announcement about wire-breaking changes for the Jazzy backport.
  • [@nuclearsandwich] ros2-gbp organization maintenance
    • The ros2-gbp organization is managed with terraform in order to scale and standardize release repository access requests. The terraform setup is relatively straightforward but it is not a tool that’s familiar or used elsewhere within the ROS community and it’s an extra step in the process of getting packages released into the ROS repositories.
    • Additionally, it’s an extra maintenance step for the ROS PMC to manage beyond basic rosdistro duties.
    • The current terraform setup was always intended to be a stepping stone toward using terraform for more integrated ROSdistro configuration. Since I’ll be stepping down at the end of the year, I would rather use the time to build that integration up rather than hand off the status quo to a new rotation of maintainers.
    • Two “default” plan possibilities:
      • we’ll decommission and archive the terraform configuration and let the ros2-gbp admins manually maintain repository permissions in the organization.
      • We hand maintenance of ros2-gbp-github-org over as part of rosdistro rotation with support from infrastructure when the deployment fails.
  • [@k-yokoyama-esol] Change of personnel and takeover of REP-2017
  • [@emersonknapp] Call attention to GitHub - emersonknapp/launch_py: Python frontend for ROS 2 launchfiles - a la YAML/XML , this bad or good idea? Works for many things if you want to try it, not feature complete
  • [@mjcarroll] Hardcoding logging macros in rcutils: https://github.com/ros2/rcutils/pull/502

As a reminder, ROS PMC meetings are open to the public, though only committers and members may speak without being called on. If you have topics that you would like discussed, feel free to respond here.

5 Likes