The ROS PMC meeting for this week was on Tuesday, August 4, 2026. The notes from the meeting are available at ROS PMC weekly meeting agenda.
ROS PMC Business
- Async Formal Decision: Rolling sync policy. PASSED (11 of 16 PMC Constituents approving).
- Decision taken by asynchronous vote under Charter Article 4.12.ii, on a matter brought under Article 4.10.i. Proposal: Rethinking Rolling Syncs.
- Votes recorded per Article 4.14:
| PMC Constituent | Vote |
|---|---|
| @christophebedard | APPROVE |
| @mjcarroll | APPROVE |
| @MiguelCompany | APPROVE |
| @tomoyafujita | APPROVE |
| @marcogg | NO VOTE |
| @ahcorde | APPROVE |
| @emersonknapp | NO VOTE |
| @clalancette | APPROVE |
| @cottsay | APPROVE |
| @sloretz | APPROVE |
| @audrow | NO VOTE |
| @morlov | APPROVE |
| @nuclearsandwich | NO VOTE |
| @alsora | NO VOTE |
| @yadunund | APPROVE |
| @wjwwood | APPROVE |
- @sloretz had asked how a manual hold on automatic syncs would work, given that the expedite path is simply running the sync-to-main job manually as we do today. That question was resolved in the meeting, allowing the vote to reach the two-thirds threshold.
- @cottsay noted that sync jobs are not automatically reconfigured by the nightly runs, so disabling the job in Jenkins would hold, and would only come back through a deliberate re-enable or deployment. A longer term option is a rosdistro flag to block syncs, which would be new work.
- The flag would likely live in
index-v4.yaml. Adding a new key does not require a new REP process, though the existing REP document should be updated by pull request. Existing rosdistro Python APIs tolerate unknown keys, which is the contract that matters. - @sloretz observed this would be useful for other distributions too, and @cottsay suggested tying it to distribution status so syncs stop automatically once a distro reaches end of life.
- @clalancette proposed opportunistically adding a “distro is frozen” field at the same time, which would support the rosdistro reviewer bot. Concern raised that a commit per freeze/unfreeze is heavyweight; @cottsay suggested a workflow dispatch that makes the commit automatically, reducing it to a button click. A freeze/unfreeze workflow is needed anyway for related work.
- Related: rosdistro#50112, via @andrew_symington.
- Volunteers wanted for two pieces of work: a sync status flag, and a frozen/unfrozen distro status. @mjcarroll will open a feature ticket.
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.
Greenness report
- Lyrical is in poor shape, with few green jobs. Kilted is also low at around 32%.
- Rolling is green while Lyrical is not, despite comparable jobs. Some of this is Lyrical builds timing out after Zenoh expanded the testing matrix, but the nightly Fast RTPS jobs are solid green on Rolling and yellow on Lyrical, which suggests something else is going on. @mjcarroll will investigate.
- The expanded greenness report (linked from the month number) breaks down which jobs are yellow versus red, which is more useful than the headline percentage.
Issues
test_tracetools.test_message_link_partial_syncfailing by timeout after freezing. Flaky, and taking 60 seconds where it should take 2. Assigned to @christophebedard; appears to be a bad test.- Missing
boolinclude in an RMW package causing widespread build regressions. Caused by a backport that scoped headers down, removing something that had been arriving transitively throughrcutils. The scoped include is the right fix; @mjcarroll will run it through CI.
Priorities
- PTAL Buildfarm Issues Triage Sheet (10 open issues).
- Some ROS 2 tests share the same name when they should be unique, which corrupts JUnit age data in the buildfarmers’ daily report and dashboard, producing tests that appear far older than they are.
- @cottsay noted test result identifiers are chosen by the tests themselves, collisions have probably always been a latent bug, and aggregation simply has not been loud about it. We should make ROS test result IDs unique and add tooling to catch collisions.
- Likely cause under discussion: a parameterized launch test spawning an executable without propagating the parameterization down to the spawned process name. @mjcarroll will take a look.
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.
- Aug 6, 2026
- @andrew_symington
- @skye.galaxy is out this week; the two will alternate going forward.
Further Baffle Maker improvements: repository descriptions on hover so you can accept or reject without navigating away, pagination showing the last two weeks first with full history behind it for backlog pruning, checkbox state persisted in browser local storage, and a source link under the title. The meeting is now efficient enough that it reached the AI-clustered items after clearing the human ones.
One correction needed: contractors who only open pull requests are being misclassified as AI, since the heuristic is a ratio of reviews and issues to PRs opened. Documentation contributions look like an outlier worth excluding.
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 4, 2026 - Aug 11, 2026
- Outgoing rosdistro
- rosdistro#52571:
python3-torchvision-pip. The package was dropped from Ubuntu after 22.04 and returns in 25.10, but is absent from 24.04 and 26.04, while remaining available across Debian and Fedora.- Resolution: add a platform-specific pip rule under the existing rosdep key rather than creating a new one. We normally avoid pip rules under non-pip-specific keys because the pip to system package transition is messy, but that concern does not apply where the package is not expected to return on those platforms.
- rosdistro#52571:
Release Management
Release Management tracks the status of upcoming releases, patches, and syncs across the active ROS distributions.
- @christophebedard (Humble)
- Roughly 700 regressions from buildfarm disk space issues (see Agenda). Sync deferred until agents are rotated.
- @yadunund (Rolling)
- No updates.
- @marcogg (Jazzy)
- No updates.
- @cottsay (Kilted)
- No updates.
- @sloretz (Lyrical)
- Regressions on a few packages; still working toward freeze and sync. Lyrical will be prioritized for job re-triggering since its backlog is smallest at roughly 200 packages.
Working Group Updates
No working group representatives were present this week due to summer vacation.
- Client Library Working Group (@alsora)
- Last meeting: Jul 24, 2026
- Next meeting: Aug 7, 2026
- Accelerated Memory Transport Working Group (@ahcorde)
- Last meeting: Jul 22, 2026
- Next meeting: Aug 5, 2026
- ROSGraph Working Group (@emersonknapp)
- Last meeting: Jul 21, 2026
- Next meeting: Aug 4, 2026 (today)
Agenda
- [@christophebedard] Widespread regressions from buildfarm disk space issues
- Every distribution except Rolling has between 200 and 900 regressions. Status pages: Humble, Jazzy, Kilted, Lyrical.
- Root cause per @cottsay: agents reach a steady state with around 30 GB free, then allocate roughly 20 GB at job startup and fail, then clean up as the job fails, returning to the pool without ever tripping the disk space threshold. The message claiming the agent was taken out of circulation appears to be an artifact of the old buildfarm and is not accurate.
- Silver lining: this means agent rotation problems have been substantially mitigated. Agents now live long enough for their caches to grow, which was not previously the case.
- Plan: force rotate all agents immediately to clear caches, trigger jobs across all platforms to clean up broken jobs, and deploy more aggressive agent offlining as an interim measure. Lyrical is prioritized because its backlog is smallest; Humble should arrive overnight.
- Longer term, regular cleanup on agents is needed. A mechanism is supposed to exist but is not working correctly.
- [@clalancette]
rosbag2 playbug with mixed-encoding MCAP files- An MCAP file containing both CDR and, for example, protobuf encoded topics causes
rosbag2 playto abort immediately, even when the requested topics are all CDR encoded. - Aborting makes sense when asked to play back topics it cannot decode, but a requested subset it can decode should play. Same reasoning applies to topic exclusion.
- No objections raised. @clalancette will work on a fix, and will bring it up again if @morlov or other rosbag2 maintainers want to weigh in.
- An MCAP file containing both CDR and, for example, protobuf encoded topics causes
- [@mjcarroll] ROS Project Handbook discussion
- Splitting the ROS PMC was raised again as an option, possibly along a plumbing versus tooling axis. ROS is the largest PMC under the OSRA umbrella, with Infrastructure next. Visualization and GUI is an obvious candidate for a split given how far downstream it sits, though a failure there would still reflect on the PMC.
- @Katherine_Scott suggested splitting the role into a tech lead and a PM role.
- Broader discussion on the value of product input: many decisions rest on longstanding assumptions that have never been re-evaluated, such as whether embedded microcontroller support, the C-only constraint, Windows, RHEL, Rust, and zero-copy are being used the way we designed them to be. Guidance grounded in something other than gut feel would help the PMC prioritize, though such a person would need to be well embedded in the robotics community already.
- On funding such a role, @Katherine_Scott asked whether contributing a full-time person could count toward OSRA membership tier, changing the incentive structure. @clalancette noted this resembles the old TSC model, whose contribution requirements were good on paper but hard to enforce. Discussion continues.