ROS PMC Minutes for August 25th, 2026

ROS ROS PMC
1

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

ROS PMC Business

  • Decisions going to an asynchronous vote this week. The ballot will be sent out shortly.
    • Promote @skye.galaxy to PMC member, sponsored by @emersonknapp
    • Promote @jmachowinski to PMC member, sponsored by @sloretz
    • Promote @andrew_symington to PMC member, sponsored by @wjwwood
    • Promote @KimMcG to committer. Sponsor and mentor still needed.
    • Promote Nadav Elkabets to committer. Sponsor and mentor still needed.
    • Promote Timple to committer. Sponsor and mentor still needed.
    • Promote Martin Pecka to committer. Sponsor and mentor still needed.
    • Move @nuclearsandwich to emeritus status
    • Move @audrow to emeritus status
  • On the outstanding committer sponsorships, @clalancette offered to take the group as a batch in a couple of weeks, since onboarding is largely teaching people processes they already work with. @mjcarroll has put his name down so the vote is not blocked.
  • @Katherine_Scott suggested turning the onboarding steps into a published checklist. @clalancette has an older new-committer presentation that could serve as a starting point.
  • Deferred: forming a Bazel Working Group, to be led by @andrew_symington. Needs a PMC member sponsor and a brief written scope.
  • ROSCon presentations were due today. The offer of feedback on talks still stands.

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.

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.

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.

  • Aug 18, 2026 - Aug 25, 2026
  • Aug 25, 2026 - Sep 1, 2026
  • Generally in good shape. A few failing and a few awaiting second approvals.
  • :warning: Non-OSI licensed content. It is the position of the foundation that non-OSI licensed materials should not be packaged and distributed by the buildfarm. This affects a number of existing packages, including the Universal Robots driver, description, and simulation packages, and example_robot_data. OSRF will handle the outreach.
    • Short-term plan: remove the affected packages, and add enforcement on package.xml license tags to the existing rosdistro automation, since a declared non-compliant license is a straightforward check. @cottsay noted it is far better to have automation say no up front than to relitigate licensing with someone after the fact.
    • The harder question is content whose licensing is not reflected in the package.xml. The new package review guidelines ask reviewers to check that license files match what is declared, but nothing re-checks a package after it is accepted, and dependencies vendored in at build time defeat inspection entirely.
    • @emersonknapp noted that scanning every file in a repository for copyright headers is straightforward to automate and could even run at build time, so we are not redistributing something we have not checked.
    • Consensus was that this is a best-effort obligation, as it is for most Linux distributions, with the complication that we accept packaging from the whole world rather than curating a fixed set. Where someone misrepresents a license, the liability sits with them, and community members have reported problems to us before.
    • This will be escalated to OSRF for a stated organizational policy on how deep license checking is expected to go, since anything beyond best effort displaces other work. SBOM generation has been raised separately as a route to European Cyber Resilience Act compliance.

Release Management

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

  • @christophebedard (Humble)
    • Last sync Aug 7, 2026 (40 new packages, 747 updates). Another likely next week.
  • @yadunund (Rolling)
    • :warning: No sync since Ubuntu Resolute became Tier 1, the longest outstanding gap.
    • Threshold-based automatic syncing approved Aug 4. Implementation with @cottsay, kicked off last week. See Agenda below.
  • @marcogg (Jazzy)
    • :warning: Last sync Jun 18, 2026, roughly 10 weeks ago. Sync and patch release overdue. @mjcarroll will reach out.
  • @cottsay (Kilted)
  • @sloretz (Lyrical)
    • :white_check_mark: Synced Aug 19, 2026: 104 new packages, 150 updates, tagged lyrical/2026-08-19.
    • Next: freeze Aug 31, sync Sep 2. Then freeze Sep 14, sync Sep 16, both before ROSCon.
    • Make releases now for maximum soak time before the Aug 31 freeze.

Working Group Updates

  • ROS Office Hours
  • Client Library Working Group (@alsora)
    • Last meeting: Aug 21, 2026
    • Next meeting: Sep 4, 2026 (agenda)
    • Discussed switching from pybind11 to nanobind, which is close to a no-op change and buys smaller binaries, faster compile times, and faster execution.
    • @jmachowinski also found a Python serialization improvement, caching module attribute lookups rather than resolving them by string each time.
  • Accelerated Memory Transport Working Group (@ahcorde)
    • Last meeting: Aug 19, 2026
    • Next meeting: Sep 2, 2026
    • Discussed incorporating accelerated transport into the SIG Physical AI reference applications, which currently use PyTorch with plans for ONNX-based models, and extending the set of converters in the buffer backend repository to cover those cases. The demos are intended to show real performance gains on real robots.
    • @nvcyc reported that Qualcomm has a pull request open against the buffer backend, reviewed by NVIDIA and expected to merge shortly. That would give us two buffer backend implementations before ROSCon.
    • Note that CI on the buffer backend repository runs but cannot meaningfully test, since the runners have no GPU. Failures are currently ignored and correctness rests with maintainers, with buildfarm release builds as the real checkpoint.
  • ROSGraph Working Group (@emersonknapp)
    • Last meeting: Aug 20, 2026
    • Next meeting: Sep 1, 2026
    • NoDL documentation
    • Documentation generation is the newest feature: a NoDL document plus the rosdoc2 sphinx extension produces generated docs for a node’s interface.
    • An observe workflow produces a best-guess NoDL description from a running node, giving an end-to-end path from an existing system to generated documentation. Tutorials are coming shortly.
    • C++ code generation from a NoDL document is in flight, covering the forward direction of generating boilerplate so you write only the algorithm. The design space is still being explored, including whole-node generation versus mixin libraries that extend a node’s interface.
    • The value over the old ROS wiki is that description, implementation, and documentation cannot drift apart.

Agenda

  • [@yadunund] Auto sync packages to main for Rolling
    • ros_buildfarm#1151 and ros_buildfarm_config#396, developed with guidance from @cottsay.
    • A new buildfarm parameter, auto_trigger_main, gates the automatic sync and will be set true only for Rolling. For each architecture, testing packages build first; if they all pass, the main job runs. A package list plus a minimum count determines whether the sync fires.
    • Decision needed: which package set to gate on. The PRs currently carry desktop, desktop_full, and simulation, with the open question of whether to include ros2_control, MoveIt, Open-RMF, and similar.
    • @clalancette argued against gating on things the PMC does not control. Large downstream projects have historically gone long stretches unreleased in Rolling, and gating on them would mean effectively never syncing.
    • @sloretz argued for desktop_full with a purpose: Rolling is the test bed for the next release, so we should sync up to what we would be comfortable releasing.
    • @cottsay pointed out this replaces the manual sync, and no ROS Boss would manually sync while regressing all of simulation, so the automatic criteria should be at least as strict as human judgement. He advocated gating on things under PMC control while leaving external projects out.
    • @yadunund described his manual practice: treat Rolling as a distribution people genuinely use, file tickets against offending repositories, and hold to roughly 60 removed packages as a ceiling.
    • @clalancette suggested using the existing percentage-of-packages control rather than a fixed count, so the threshold does not need periodic bumping. Rolling currently has around 1300 binary packages against a gate of roughly 450 to 500.
    • Outcome: gate on desktop_full plus a percentage threshold. Thresholds can tighten on the runup to a release, controlled by the Rolling ROS Boss with input from the next release’s ROS Boss. The manual sync path remains available as a break-glass option, though nobody could describe a realistic case for overriding the automation.
    • A useful side effect: when a sync does not fire, the reason is legible and attributable rather than falling on the ROS Boss.
  • [@cottsay] Build requirements and out-of-memory failures (Zulip thread)
    • Out-of-memory and channel-closed exceptions on the buildfarm have been climbing. Some of this is outside our control as compilers do more aggressive optimization, but a good deal is in the payload rather than the infrastructure.
    • Using an AI with a test harness to iterate, @cottsay found straightforward refactors in one of the worst offenders, the RViz visual testing framework, which the buildfarm builds despite it going effectively unused for years. Some compilation units run upwards of two gigabytes each, which no amount of job scheduling can accommodate.
    • Three asks:
      • Someone on the PMC to pick up this work. @cottsay has infrastructure commitments and limited cycles for it.
      • A way to survey for problem compilation units at scale. Out-of-memory conditions destroy the context on the worker, so pinpointing RViz visual testing took a long time.
      • Smarter resource coordination in colcon, potentially via a GNU jobserver. Worth doing, but mitigation rather than solution, and it does not help non-colcon builds.
    • Discussion turned to rclcpp.hpp, a convenience header that pulls in effectively all of ROS. It is reasonable in tutorials, where brevity matters, but library authors should not include it in headers, because every downstream consumer then pays to unroll it. There are around 500 instances in core packages.
    • Proposal: add an ament lint forbidding the header in core packages, independent of what we do with examples. @Katherine_Scott cautioned that whatever appears in the docs is what people will copy, so tutorials need at minimum a caveat. @wjwwood noted that following include-what-you-use properly would make tutorial include lists considerably longer.
    • @ahcorde has been doing this header cleanup already and will continue across packages this month, which should improve compile times more broadly.
    • :warning: Reviews needed. @ahcorde has header cleanup PRs open for around a month without review. The agreed approach is to post a running list to Zulip; @mjcarroll and @wjwwood will prioritize from there. This is also good work for new contributors and could be organized as a per-package header audit.
1 Like