ROS PMC Minutes for November 11, 2025

[mjcarroll]

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

ROS PMC Business

• Proposal: Michael Carroll proposes to mentor Michael Carlstrom as a ROS PMC Committer (Article 7.8.iv)
  • @mjcarroll makes the motion
  • @ahcorde seconds
  • Pass by consensus

Regular Business

Buildfarm update

• PTAL Buildfarm Issues Triage Sheet
• ROS Greenness:
  • October report
  • Greenness history
• Humble jobs haven’t run in a while (investigation)
• Issues
  • test_allocator_memory_strategy failing in Rolling Connext CI (Michael will take a look)
• Priorities
  • rmw_connextdds support message making ROS2 CLI tests fail (Michael assigned)
  • sros2.test.sros2.commands.security.verbs.test_generate_policy_no_nodes.test_generate_policy_no_nodes failing consistently in Kilted CI (Michael assigned)
  • The RecordIntegrationTestFixture.can_record_again_after_stop test is tend to be flaky (Michael Orlov assigned)
  • ros2service.ros2service.test.test_cli.test_cli failing consistently in Kilted (Scott assigned)
  • ros2cli daemon get publishers and subscribers by topic test failing in connextdds (Pending review of skip history and depth check for rmw_connextdds. by fujitatomoya · Pull Request #1064 · ros2/ros2cli · GitHub)

Waffle note-taker

Waffle is a weekly meeting where maintainers triage incoming issues and pull requests that haven’t been otherwise acted upon. One person per week is assigned to be the “waffle note-taker” to both take notes in the meeting to keep the meeting as efficient as possible.

• Nov 6 + Nov 13 - @sloretz

Rosdistro assignments

Rosdistro is a weekly assignment to monitor incoming issues and pull requests in GitHub - ros/rosdistro: This repo maintains a lists of repositories for each ROS distribution. Two people per week are assigned to be the rosdistro maintainers.

• Nov 4 - Nov 11 - @marcogg and @Yadunund
• Outgoing rosdistro

Release Management

• Audrow (Humble)
  • No updates.
• Yadu (Rolling)
  • No updates.
• Marco (Jazzy)
  • No updates.
• Scott (Kilted)
  • Announce today, freeze Wednesday, sync Thursday

Agenda

• [@emersonknapp] Proposal to create a ROSGraph Working Group. Find the charter at: ROSGraph Working Group - Google Docs
• [Waffle Triage] Should we switch from ament_python to ament_cmake (+ament_cmake_python) in tutorials?
  • GitHub · Where software is built
  • @mjcarroll I see three alternatives
    • Add ament_cmake as a parallel track to the tutorials
    • Remove ament_python entirely from the tutorials
    • Bring ament_python to parity with ament_cmake
  • [scott] we should prioritize creating a document showing what capabilities each type of build has:
    • Cmake vs ament_cmake vs python
    • Bringing python to parity is a good long term goal in the context of “pip install ros”
  • [emerson] as a datapoint: our (internal) style guide is biased exclusively to ament_cmake
  • [shane] should there be a REP if this is tool-facing?
    • @cottsay (I think) more package developer facing
• [@cottsay] colcon dependency isolation during builds
  • 0.20.0 and newer
  • COLCON_FEATURE_FLAGS=restore_build_isolation

[Griffin_Tabor]

@mjcarroll

[Waffle Triage] Should we switch from ament_python to ament_cmake (+ament_cmake_python) in tutorials?

• Basic python publisher / subscriber tutorials only show ament_python · Issue #5983 · ros2/ros2_documentation · GitHub
• @mjcarroll I see three alternatives
  • Add ament_cmake as a parallel track to the tutorials
  • Remove ament_python entirely from the tutorials
  • Bring ament_python to parity with ament_cmake
• [scott] we should prioritize creating a document showing what capabilities each type of build has:
  • Cmake vs ament_cmake vs python
  • Bringing python to parity is a good long term goal in the context of “pip install ros”
• [emerson] as a datapoint: our (internal) style guide is biased exclusively to ament_cmake
• [shane] should there be a REP if this is tool-facing?
  • @cottsay (I think) more package developer facing

As the author of this issue, I am happy to see it was discussed. I was lecturing exactly during the meeting so I couldn’t attend.

I find it easier to onboard new students with ament_cmake for all packages and avoid getting into the weeds of when/how to use different methods for different packages. The new user experience coming to the tutorials might think “O, I only want to write python code” and choose to follow the python tutorials. Then try to add a message from the message tutorials, a random user thinks you must need both a setup.py AND a cmakelist which is clearly not the desired workflow.

I had originally been picturing the parallel track answer, but that was because I assumed there is a user base that finds the ament_python the right choice. The parallel track answer does still have chances of the above problem, trying to combine the message and publisher tutorials together for anyone following the ament_python publisher tutorial.