ROS PMC Minutes for July 28, 2026

ROS ROS PMC
, ,
1

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

ROS PMC Business

  • Async Formal Decision: Rolling sync policy. The proposal has been posted for a week with no negative feedback, so @mjcarroll will send the async vote out this afternoon. It enables automatic Rolling syncs to main.
    • The Rolling ROS Boss will own the threshold, with input from the next release’s ROS Boss once that person exists. @yadunund holds the lever for now, with the expectation that someone monitors the situation and tightens the threshold as we approach a release.
    • @clalancette asked that we keep a close eye on the state of main for at least the first few weeks after this goes live, to make sure we aren’t syncing garbage through. @yadunund agreed to watch it.
    • @yadunund noted this could free up time for more regular Bloom releases on Rolling, since Bloom is still required and will not automatically pick up a tag from the rolling branch.

Regular Business

Buildfarm update

The buildfarm builds and tests ROS packages across all supported distributions and platforms. This section covers new issues, current priorities, and infrastructure changes that affect maintainers.

  • :new_button: Issues
    • No new issues opened this week.
  • :warning: Priorities
    • PTAL Buildfarm Issues Triage Sheet (10 open issues). Most have had no updates in three or four months, and notes have been added to them. Eyes on these would be much appreciated.
    • Unblock rolling and lyrical cyclone jobs build regressions. The Cyclone jobs were stuck on an ignored Fast DDS dependency; adjusting the ignore rule surfaced a second ignored dependency.
      • Resolution: Cyclone has no rosidl buffer implementation (only Fast DDS and Zenoh, the latter having landed recently), confirmed by @nvcyc. The buffer test can safely be skipped for Cyclone until such support exists.

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.

First impressions of the Baffle Maker board were positive. @skye.galaxy reported that filtering contributors by who is actually a human likely to respond meant the meeting spent far less time discussing how AI writes and far more time getting issues assigned.

The board still lives on a personal GitHub Pages site. Moving it under ros2/pmc_scripts is on the horizon.

Rosdistro assignments

Rosdistro is a weekly assignment to monitor incoming issues and pull requests in GitHub - ros/rosdistro. Two people per week are assigned to be the rosdistro maintainers.

  • Jul 21, 2026 - Jul 28, 2026
  • Jul 28, 2026 - Aug 4, 2026
  • Outgoing rosdistro
    • osqp (#52852)
      • osqp_vendor is maintained by TIER IV and has effectively been abandoned; the maintainer took several months to respond. OSQP is a critical dependency for getting MoveIt working on Lyrical and Rolling.
      • Consensus is to let MoveIt fork and own the vendor package. @clalancette noted this keeps it clearly a vendor package rather than injecting content after the fact, and that the URL can always be changed later if TIER IV does agree to transfer ownership. @MiguelCompany suggested proposing a direct ownership transfer as a follow-up step.
      • Related discussion: injecting a package.xml at Bloom time (rather than shipping one upstream) is a legacy ROS 1 pattern that still works but is no longer preferred. Vendor packages give far more control, including building conveniently in a source workspace and moving versions. Vendor packages are also only accepted in service of a ROS package; we are not trying to package the world.
    • rqt_teleop (#50546)
      • The name is arguably too generic given rqt_robot_steering already exists. @yadunund noted the implementation targets twist-controlled robots, while teleop covers arms and many other robot types.
      • @sloretz leaned toward leniency, since the rqt_ prefix already scopes it to a plugin for moving a robot around. @wjwwood preferred a twist-specific name on the grounds that more specific is usually better, while acknowledging it becomes awkward if they later add other teleop types.
      • Outcome: suggest a twist-specific name such as rqt_teleop_twist.

Release Management

Release Management tracks the status of upcoming releases, patches, and syncs across the active ROS distributions.

  • @christophebedard (Humble)
    • No updates.
  • @yadunund (Rolling)
    • No updates.
  • @marcogg (Jazzy)
    • No updates.
  • @cottsay (Kilted)
    • No updates.
  • @sloretz (Lyrical)
    • A fix for one regression has merged and the last few are being stamped out. The sync is expected to land this week.

Working Group Updates

  • Client Library Working Group (@alsora)
    • Last meeting: Jul 24, 2026
    • Next meeting: Aug 7, 2026
    • The author of the Python/Zenoh ROS client library recently posted about on Discourse joined the meeting, and the group discussed the asyncio executor.
  • Accelerated Memory Transport Working Group (@ahcorde)
    • Last meeting: Jul 22, 2026
    • Next meeting: Aug 5, 2026
    • Discussed bugs fixed over the last two weeks. Backporting to Lyrical is in progress but is hitting a consistent failure across all four platforms; reviews appreciated.
    • A PR is also open to clean up an extra topic being advertised by some rqt packages.
  • ROSGraph Working Group (@emersonknapp)
    • Last meeting: Jul 21, 2026
    • Next meeting: Aug 4, 2026
    • No representative present, though the group is reportedly making good progress on implementation work.
  • Lyrical Release Working Group (@sloretz)
    • Done! The retrospective was presented last week and is well worth a read if you missed it.

Agenda

  • [@mjcarroll] ros2/ros2_terraform
    • An experiment in capturing the current state of GitHub permissions across our organizations as a Terraform description, with the goal of applying the PMC structure uniformly across the ROS 2 repositories. Branch protection would be unified the same way.
    • Roughly 60 people are expected to lose access to the ros2 and ament organizations. Committers and PMC members are not affected. The people impacted are those holding write or CI access without being committers, including accounts left over from organizations and projects no longer involved with ROS. Anyone who wants to keep that access can be voted in as a committer, which is straightforward.
    • @clalancette asked that affected people be collected and notified via a Discourse post, and by email where possible, before any access is revoked, to avoid the appearance of a unilateral change.
    • @mjcarroll agreed: currently active people will be invited to become committers rather than losing access, while inactive accounts (roughly a year or more with no commits) would be removed. A warning will go out well before anything is applied; this is not happening in the next few days.
  • [@mjcarroll] ROS Project Handbook discussion
    • Context: OSRF staff and the TGC asked for a written scope of the ROS Project Lead role, to make it easier to approach potential project leads and their employers. This became an opportunity to write down the rhythms of the project year and to split up responsibility as the project grows.
    • The motivating idea is that named roles with clear scope make it easier both to volunteer and to justify the time to an employer. Each role would carry delegated decision-making authority up to the point where something needs to be surfaced to the PMC.
    • Roles discussed:
      • PMC Lead (@mjcarroll).
      • Project Representative (@ahcorde). Proposal is to make this the formal point of contact for the TGC and member organizations, so asks route here rather than to the project lead. @ahcorde agreed the role currently carries few defined responsibilities and would welcome more.
      • Triage lead. Formalizing the work @andrew_symington and @skye.galaxy have been doing on the incoming issue and PR firehose. Likely staffed on a rotation of around three months rather than a year.
      • Rosdistro lead. A single person responsible for improving the rosdistro process rather than only staffing the weekly rotation. Ideas raised include automatic Bloom releases into Rolling, the automatic Rolling to main sync, and reconsidering whether human review is needed for patch or version-increment releases from an already authorized maintainer.
      • Infrastructure and buildfarm liaison. Arguably already exists via @cottsay. The gap is closing the loop: we get good feedback from the buildfarmers but do not always act on it. This is a revival of the old “build cop” concept, responsible for follow-up rather than for doing all the fixing.
      • Security officer. Currently falls to the PMC lead. This is growing in importance: the TGC is standing up a security subcommittee, since OSRF has obligations under the European Cyber Resilience Act to publish known vulnerabilities to downstream users. @tomoyafujita has expressed interest at both the PMC and TGC level.
      • Community and working group coordinator. Effectively @Katherine_Scott today.
    • @mjcarroll considers PMC Lead, Project Representative, and Security Officer to be the non-negotiable ones.
    • Guilds. A separate concept: named areas of the stack with a couple of people each, so any incoming PR has an obvious reviewer, and so newcomers have a defined area to join. These are deliberately not working groups, since the charter requires a working group to have a specific goal and duration.
    • Feedback:
      • @sloretz observed that this is a lot of roles and would prefer fewer, while agreeing these are all things we either do or should be doing. Following up on buildfarmer feedback is currently left to volunteers and falls through the cracks.
      • @Katherine_Scott argued that a larger number of roles is not itself bad if it means responsibility is clearly delegated instead of landing on one person. She also asked whether external projects such as ros2_control, Gazebo, and Open-RMF fall under the community coordinator’s scope; @mjcarroll would put those, along with MoveIt and Nav2, under the community umbrella.
      • @skye.galaxy supported splitting things up by area, noting the Client Library Working Group frequently touches areas that overlap its nominal scope, and asked how a guild would differ from a working group in practice in terms of meeting cadence.
      • @clalancette likes splitting up the topic areas but is concerned about spreading people too thin: if every PMC member holds a role, it is worth asking who is left doing the work. He also noted the Client Library Working Group is something of a one-off among current working groups in that it is ongoing rather than goal-and-duration scoped.
      • @wjwwood pointed out that the purpose of the titles is not to increase output directly, but to make it easier for people to justify spending time on well-scoped work. That value holds even if nothing else changes.
      • @mjcarroll acknowledged the risk that everyone ends up with a title and no work gets done. This only works if the group treats bringing in more people as a high priority, even at some cost to individual contributor time, and starts thinking about developing the pipeline of talent behind the current PMC.
    • Discussion continues async so contributors in other time zones can participate. Feedback on the document is very welcome.