ROS PMC Minutes for September 29, 2026

ROS ROS PMC
1

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

This was the first meeting back after ROSCon.

ROS PMC Business

  • :white_check_mark: REP 158 PASSES. The OpenUSD conventions for simulation asset interoperability are accepted.
  • New committer candidates coming out of ROSCon. @robwoolley + @saikishor
  • :warning: ROS Project Leader. October 1 is @mjcarroll’s last day as project lead. @ahcorde has put himself forward as a candidate. Formal vote this week.
  • :memo: PMC members: link your ROSCon presentations. The ROS documentation has a section for presentations given by PMC members. ROSCon talks — ROS 2 Documentation: Rolling documentation

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 (three new, covering two weeks, most opened ahead of ROSCon)
    • A consistent test timeout, not Windows specific and not connext specific. Initially suspected to be asyncio executor related, but @clalancette pointed out the affected code does not use asyncio. @clalancette picked it up and will look this week.
    • A second timeout, Windows only. @mjcarroll took it.
    • A Cyclone DDS issue where a package reads an empty vector or reads out of bounds, driving four test regressions. The visible warning looks unrelated, but @clalancette noted the last failure involves intraprocess and appears to segfault or at least crash. Related to the read socket buffer.
      • @miguelgonrod noted that the Cyclone DDS maintainers have not responded to most of the issues we have open.
  • :warning: Priorities

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.

  • Oct 1, 2026
    • @skye.galaxy
    • Expected to be a banner week. This is the first Waffle after ROSCon and the most likely to draw new faces.

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.

Release Management

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

  • Humble, Jazzy, and Kilted syncs all went out in mid September.
  • @yadunund and @cottsay (Rolling)
    • :warning: Automated Rolling syncs are still blocked. @cottsay needs to deploy @yadunund’s latest round of changes to the test farm to confirm the build aborting behavior works correctly. Checking upstream builds and aborting properly is a pattern used elsewhere, but this implementation is novel enough that it needs to be exercised before it goes live.
  • @cottsay (Kilted)
    • :warning: Kilted end of life is November, about six weeks out. @cottsay plans a final patch release as part of the end of life.
  • @sloretz (Lyrical)
    • A sync is planned for this week. There are a few regressions with no confirmed root cause yet; the plan is to work out what to revert to get back to green.

Working Group Updates

  • ROS Office Hours
    • :date: Joint ROS and Gazebo office hours on Friday, October 9, 2026. Not this Friday, next Friday. Please turn out for it.
  • ROSGraph Working Group (@emersonknapp)
    • Next meeting: Sep 29, 2026 (today). Expect new faces after significant ROSCon interest.
    • :light_bulb: Open discussion about absorbing generate_parameter_library as a subcomponent of the NoDL project. It is currently owned by PickNik, and the maintainers appear on board with moving it to ros-tooling and treating it as part of the NoDL implementation.
  • Client Library Working Group (@alsora)
    • Next meeting: Oct 2, 2026. @skye.galaxy and @jmachowinski used their ROSCon talks as a call to action to join the group, so expect new attendees.
  • Accelerated Memory Transport Working Group (@ahcorde)
    • Next meeting: Sep 30, 2026.
  • SIG Physical AI
    • Next meeting: Oct 2, 2026.

Agenda

  • [@mjcarroll] Fill out the ROSCon survey. Feedback guides the kind of content, structure, and format we see in future years.
  • [@mjcarroll] Fill out the annual Open Robotics survey, new this year. What you use and what you do not use both matter, because this feedback sets the direction of the OSRA, which in turn sets the direction of the projects.
  • [Sayan Paul, Red Hat] ARM64 RPM packages. Red Hat is enabling ROS on a set of mostly ARM based boards and is looking for ARM64 RPM packages for Lyrical and Rolling.
    • The buildfarm does not currently produce ARM64 RPM packages at all.
    • @cottsay does not expect meaningful ARM specific fallout, since we already have the intersection of RPM builds and ARM builds on the deb side. This is largely a resource allocation question: roughly 1500 additional jobs per distribution, so Rolling plus Lyrical would be about 3000.
    • Next steps are to talk to the buildfarm folks about what that costs, and to Red Hat about whether further buildfarm investment is in budget.
    • On the missing packages (Pinocchio, some Nav2 packages) the answer is to chase the upstreams directly.
  • [@cottsay] Drawing a clearer line around PMC maintained packages. A security report came in today for a repository the PMC does not maintain.
    • We do not have a good story or good documentation here, and routing community maintained package problems through the PMC only delays resolution. For anything not maintained by the PMC, the community should go directly to the package maintainers; we are just the infrastructure at that point.
  • [@clalancette] Pull request build hooks. @cottsay dug into the root cause before doing the work to update every hook, and believes he has found what went wrong, with help from @Crola1702.
    • The planned change to redeploy all the hooks assumed we needed to program a secret that was not previously present. A secret like this is global, and if everyone using the buildfarm for pull request builds knows it, it serves no purpose, which is exactly how things were configured before.
    • The new plan is to restore the buildfarm to its previous state with no secret at all, and clean up only the couple of repositories that moved forward rather than all of them. This also avoids a Discourse post and coordination with the broader community for repositories we do not control.
    • It is being tested on the test farm first. Nothing is needed from @clalancette; @cottsay will ping the thread.
  • [@clalancette] CI and CD requirements document. Coming out of ROSCon conversations about what we actually want from CI and CD in the ROS project. Our infrastructure has grown organically rather than by design, and things take too long.
    • The document is deliberately a requirements list, not a design or a tool selection. Specification and design would follow, so we can see how to move from where we are toward where we want to be.
    • This is inherently cross PMC between infrastructure and ROS. Everyone should read it and comment: missing requirements, disagreements, edits. Comment permissions are open; say so if they are not.
    • On overlap with the proposed CI/CD SIG: the proposal went to the TGC to decide funding allocation. The original reasoning was that the ROS and infrastructure PMCs are overburdened enough that nobody would stand up a SIG without funding attached to make it a priority.
  • [@emersonknapp] A place for evergreen writing. Prompted by describing the thin node pattern in his ROSCon talk and finding it was not written down anywhere.
    • The gap is architectural patterns and opinions about how to use ROS, which do not obviously belong in the docs project.
    • Discourse has the highest bandwidth and, as @tfoote noted, is genuinely good at SEO and discovery, with content staying findable for years. @Katherine_Scott confirmed old posts still draw real traffic.
    • The counterpoint is that Discourse is an announcement channel rather than a store of curated content.
    • Resolution: @emersonknapp will start a ros-tooling working group blog, most likely Docusaurus, the same as the NoDL page, and announce posts on Discourse. If it wants to move later, it can move. @Katherine_Scott noted the working group level also gives more autonomy.
    • @tfoote flagged that Discourse has a lot of unused flexibility in its landing page, and highlight articles are an option if we want to customize that experience.
  • [@mjcarroll] ROSCon debrief, from the shared notes document. Only the first part was covered; the rest carries to next week.
    • Potential contributors and maintainers. @Katherine_Scott has the hackathon email list. @robwoolley and Sai are the two strongest committer candidates. Someone approached @skye.galaxy after her talk with ideas for making the executors faster, but the name was not caught.
    • Working group discoverability. @emersonknapp received direct feedback that working groups are hard to find. The entry point today is a Google doc or an embedded Google calendar that gives you every group’s invites at once. @Katherine_Scott proposed a static landing page per working group, possibly on a subdomain, with an index on docs.ros.org. @mjcarroll noted the groups should be straightforward to enumerate since real working groups have charters on file.
    • macOS. We do not need macOS to be Tier 1, but we do need a golden path for ROS and Gazebo that largely works. The current approach is fragmented, with Gazebo going through Homebrew and various community efforts doing their own thing. @mjcarroll would prefer standardizing on Pixi. @KimMcG noted from the workshop that building on macOS does not mean it runs and behaves as expected, so this also needs testing and tutorial resources.
    • Pixi versus curated platforms. @cottsay raised the elephant in the room: we plan significant investment in Pixi and the prefix.dev folks are on board, but Pixi is entirely rolling while our workflows, tooling, and distribution model are built on stable, curated, security patched foundations. CMake 4 is the easy example, but any dependency can roll forward and break us mid cycle.
      • A centralized pixi.lock worked well for the core packages but does not scale to the distribution level, and is not something the team can maintain as we expand past PMC maintained packages.
      • @clalancette pinned Pixi tightly on purpose after Homebrew proved unsustainable. The result is reproducible builds with no CMake 4 style surprises, but also no security uptake.
      • @mjcarroll suggested the middle ground of version ranges rather than exact pins, closer to Python packaging, which is spiritually similar to how the Bazel pins work.
      • @andrew_symington noted Bazel pins all upstream dependencies explicitly, so a stable pin and a rolling pin are both possible. He also reported a relatively clean macOS Bazel build including Qt, and believes a full Bazel build up to desktop is achievable given the hours to convert the files.
      • @tfoote noted the Bazel pin files are generated semi dynamically from rosdistro on Ubuntu, and similar automation could keep Pixi constraints aligned.
      • @mjcarroll pushed back on anchoring to Ubuntu or Debian versions, given how those choices have played out over recent LTS releases. @clalancette countered that constructing a solvable package set from scratch is much harder than it looks, as he found working backward for Humble.
      • @wjwwood noted Homebrew did help keep Rolling current, and that pinning trades one set of problems for another rather than eliminating work.
      • This needs to be captured somewhere, either a document or a dedicated meeting.
    • “Less is more” resonated widely. If something about ROS 2 has been bothering you, raise it. Not everything can be ripped out and rewritten, but where it makes sense, there is latitude to do it.
1 Like