ROS PMC Minutes for July 21, 2026

ROS ROS PMC
, ,
1

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

ROS PMC Business

  • TGC meeting Thursday, July 23, 2026 to discuss funding proposals. The ROS Project submitted four:
    • A joint SIG proposal with the Infrastructure PMC to improve continuous integration.
    • A joint proposal with Gazebo on canonical examples for the ROS Project.
    • Improvements to the ROS logging mechanisms (from the Client Library Working Group).
    • Coding agent subscriptions for maintainers (@jmachowinski).
    • @mjcarroll and @ahcorde will represent the ROS Project.
  • Formal Decision (asynchronous vote): PASSED. Creation of ros2/pmc_scripts (original proposal), brought forward by @sloretz. This is a PMC-owned, Apache-licensed home for scripts that maintainers and committers find useful. It currently holds little more than the waffle-maker script, so contributions are welcome and encouraged.

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; @miguelgonrod will file a few from ongoing investigations.
    • Stale issues that are no longer reproducing have been cleaned up. Comments have been left on most of the remaining open issues; several are long-standing regressions that are non-trivial to fix.
  • :warning: Priorities
  • The Buildfarmers dashboard is finished and deployed. Feedback and bug reports are welcome on the Zulip thread.
    • Note for maintainers: the dashboard links test failures to known issues by matching test names against the buildfarmers’ issue database. This is not fully automatic. If you open an issue for a test failure, please ping the buildfarmers so it can be tracked and linked.

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.

@andrew_symington demoed Baffle Maker, a new triage aid for the Waffle meeting (live board, PR #2). It wraps the existing waffle-maker script, scrapes contributor metadata, and clusters open PRs into likely-human, unknown, bot, and likely-AI buckets, with a marker for project members and a flag for undisclosed AI usage. The goal is to spend the meeting’s limited time giving meaningful feedback to human contributors first. It regenerates via CI each morning and will be tried out at this week’s Waffle meeting.

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.

Working Group Updates

  • Client Library Working Group (@alsora)
    • Last meeting: Jul 10, 2026
    • Next meeting: Friday, Jul 24, 2026
    • @skye.galaxy is publishing the agenda in advance so others can add items.
  • Accelerated Memory Transport Working Group (@ahcorde)
    • Last meeting: Jul 8, 2026
    • Next meeting: Wednesday, Jul 22, 2026
    • Qualcomm is working on a buffer implementation, which would be the first non-NVIDIA one and a good validation of the work done during the design phase.
  • ROSGraph Working Group (@emersonknapp)
    • Last meeting: Jul 7, 2026
    • Next meeting: Tuesday, Jul 21, 2026 (this afternoon)
  • Lyrical Release Working Group (@sloretz)
    • Retrospective presented today (see Agenda below).
    • This is expected to be the group’s final deliverable and the end of the working group.

Agenda

  • [@sloretz] ROS Lyrical Retrospective
    • Presentation and full report. The retrospective, not the release itself, is the declared output of the working group. TLDR below; the full report has considerably more detail.
    • Release process
      • Pick the ROS Boss much earlier. Lyrical’s was chosen roughly 3 months out and the role was effectively full-time from that point, while platform migration work had begun as early as January without a dedicated point of contact. We should also establish a policy for when future ROS Bosses are appointed.
      • Make ROS bossing take less time, since much of the effort was just figuring out what to do. Recommendations: write detailed, PR-able instructions (e.g. in the ROS 2 documentation governance pages), consolidate helper scripts into one place (pmc_scripts is now a good home), and draft announcement templates so releases are easier to delegate when the ROS Boss is unavailable.
      • Weekly working group meetings were valuable, and there was never a meeting with nothing to discuss. Recommend starting them earlier than two months before the release.
      • The RMW freeze slipped by a week. It produced a much better state, but disrupted testing plans for people outside the PMC. Future deadline changes should be decided early and loudly. Worth exploring ways to incentivize RMW updates well before the freeze.
    • Development
      • Get official Docker/OCI images out earlier. The tutorial party started before they were available, and many people rely on them both for testing and in their own CI. Image availability should be an explicit item on the release timeline.
      • Roll Rolling onto new platforms sooner, announce and sync Rolling well in advance, and consider automating rolling to main syncs. This gives more runway for breaking changes and avoids pulling the rug out from under people expecting one more sync.
      • CI time is a compounding drag: Windows jobs reached nine hours, and backlogs spiked before deadlines. Some of this may be over-testing, since full CI on low-risk changes was common.
      • Linting is causing disproportionate pain (a flake8/pycodestyle incompatibility blocked version bumps on Windows). Linting requires a full build and pins us to platform-specific linter versions. Suggested directions: decouple linting from the build, vendor the linters, and/or run them as a fast pre-commit or GitHub Actions check so contributors get feedback immediately. @skye.galaxy and @mjcarroll both noted this is increasingly valuable now that agent-assisted contributions often arrive without local testing.
    • Testing and tutorial party
      • Strongly continue it. Roughly 110 people ran a couple thousand test cases. Participants felt appreciated and publicly recognized, and the Zulip channel worked well. Keep the recognition and the prizes; prizes may be worth including in a future funding proposal.
      • Test case generation cannot happen at the last minute. Migrating YATAM v1 to v2 late in the cycle produced thousands of invalid combinations that were hard to filter. Test cases likely need continuous curation and better programmatic tagging (platform-specific, RMW-specific), and it’s worth evaluating purpose-built open-source test case management tools instead of generating GitHub issues.
      • Sequential tutorials are a poor fit, since asking someone to test step 7 of 10 requires them to do steps 1 through 6 first. Prefer self-contained tests.
      • Triage of incoming tutorial party issues fell to very few people, largely @Katherine_Scott and @ahcorde. Recommend a formal on-call rotation for both responding to testers and validating/fixing reported bugs.
      • Test results are only as good as the tester’s setup. Reused environments and wrong RMW settings produced misleading results; notably, a Connext package shipped with a missing shared library despite passing tests. Next time, standardize the environment (e.g. a prescribed Docker image or a clean-shell tool).
      • @azeey noted that conceptual and explanatory documentation is a poor fit for tutorial party, since newcomers can’t assess correctness. Curation should favor “do this, observe that” content, precisely the things that are hard to automate.
    • Discussion
      • @yadunund asked whether the more federated model should replace the formal release teams of past cycles. @sloretz noted the federated approach worked remarkably well, but that formal assignments can make it easier for contributors to justify the time to their employers. That matters given this release consumed roughly one FTE for three months.
    • Top three priorities
      • Appoint a ROS Boss for ROS Makoa as soon as possible (roughly 300 days out).
      • Document the release process itself.
      • Reduce CI time.
  • [@mjcarroll] Rolling sync updates
  • [@mjcarroll] ROS Project Handbook discussion
    • Shared with the TGC and other project leads, and posted to Zulip.
    • Addresses ROS Project governance going forward, with an eye toward reducing the burden on future ROS Project Leads. Feedback welcome.
  • [@andrew_symington] Lyrical in Bazel via the ROS Central Registry
    • lyrical.2026-06-08.rcr.1 has landed in the ROS Central Registry, with a package browser frontend.
    • Builds and tests up to the perception variant.
    • Native builds on arm64 and x86_64, on both Linux and macOS, so no Linux VM is needed on Mac.
    • Hermetic LLVM toolchain, smaller and faster than toolchains_llvm.
    • Middleware switchable at runtime via RMW_IMPLEMENTATION.
    • Portable ROS nodes with typesupports/RMW statically linked in.
    • CI workflow warms the cache, reducing time to first build.
    • Intermediate cc_shared_library targets, a step toward generating tar layers resembling underlays.
3 Likes
Has a CPU shared-memory backend for rosidl::Buffer been explored?