ROS 2 TSC Meeting Minutes 07-21-2022

General
1

ROS 2 TSC Contribution Report 2022-07-21.pdf (123.3 KB)

ROS 2 TSC Meeting Minutes for 2022-07-21

  • Attendees
    • Jaime Martin Losa - eProsima
    • Ralph Lange - Bosch
    • Toffee Albina - Toyota Research Institute
    • Kat Scott, Chris Lalancette, Louise Poubel, Geoffrey Biggs, William Woodall, Audrow Nash - Open Robotics
    • Aaron Blasdel - Amazon
    • Angelo Corsaro – ZettaScale
    • Tyler Weaver - PickNik Robotics
    • Lou Amadio - Microsoft
    • Hanif Zaini – ROS Industrial
    • Brett Aldrich,
    • Patrick Musau
    • Will Son - ROBOTIS
    • Jeremie Deray (artivis) | Canonical
    • Phillippe Couvignou
    • Adrian Macneil– Foxglove
    • Christophe Bedard
    • Darryl Lee
  • Preliminaries
    • [Kat ][1 min] Please remember to fill out your contribution report at the bottom of this document prior to the meeting.
  • Old business
    • Follow up on ROS 2 Humble Docs
  • New business
    • [Lalancette | 20min] Results Default DDS Poll / Discussion of Results
    • TLDR – resolved: we will revisit the default DDS vendor in K turtle (next non-LTS ROS release after Iron) and all Subsequent non-LTS releases.
      • Open Ended responses:
        Forms response chart. Question title: How would you prefer that the default RMW provider for ROS 2 be chosen?. Number of responses: .
        How would you prefer that the default RMW provider for ROS 2 be chosen?1600×695 75.4 KB
        • Consistency over time is preferred.
        • I am in favor of stricter boundaries around “the ROS project” (as owned by the TSC). Fast DDS is not part of ROS, any more than PostgreSQL is part of Rails - it is a dependency, chosen by the TSC based on what we believe will provide the best experience for new users. Other alternative middlewares are provided for those who need them. We should only change a default dependency when a strong case is put forward (with the onus on the change proposer to bring data supporting such case, as with any other technical change). Agreeing to a regularly scheduled re-evaluation of defaults means accepting a ton of evaluation work (high cost) and I have not heard any clear explanation of the benefit (other than politics - DDS vendors understandably want to score marketing points by being the default, but that should have zero influence on how “the ROS project” is governed). Fallback thought: Changing the default on an LTS release might be a bad idea (e.g. Ubuntu doesn’t usually introduce major changes to LTS releases). Maybe we should consider that and only change the default on a non-LTS year.
        • The options posed are great. My votes are what I think are best for new users, and generally out of box experience. WRT having a neutral party write the report, I would propose that non-vendor TSC member(s) is responsible. Having a mini (or full) task force from the TSC would keep costs lower, and the efforts could even count towards those companies contributions for the month. Lastly, I have fairly strong feelings that if the two reports are not written using the same infrastructure (testing tools, profiling tools, and configurations), we unfortunately waste a lot of time. This to me is an additional benefit of having a neutral party write the reports, since they’ll naturally use the same tools for collecting data in each available RMW.
        • Develop automated benchmark tool on ROS2 to evaluate performance of different DDS options and generate report for decision. The real value of ROS2 is to provide an open framework to accommodate different DDS solution.
        • I think the RMW selection should be a technical decision rather than a political one. A technical report and a votation is the most transparent way to ensure this, and maintain ROS 2 as an open project
        • Default RMW implementation should support all RMW interfaces.
        • The so far bumpy roll out of Fast-DDS as the default highlights why its important to have the votes and change / make decisions every distribution. We probably should not have changed DDS vendors at an LTS distribution and only change them on non-LTS distributions so that by the time we get to an LTS distribution, we have 1 full distribution to find and resolve any major issues so we don’t ship an LTS distribution with large issues.
        • As much as I’d like to deal with the politics, I think that this is a case where Open Robotics being the BDF L makes sense. It’s in our strong interest to have the best experience for the users. And we can maintain that role and I would recommend getting the TSC to explicitly endorse that process where the Tech Lead of the ROS project at Open Robotics will get the final decision.
        • There are really 2 questions in 1 here - decision process & decision cadence. Both could (should?) be addressed separately. Personally my first choice would be for a change on odd years (non-LTS, offering time to smooth or even revert a decision before the next LTS) motivated by a neutral party analysis.
        • Resolution: We will revisit default DDS vendor in K turtle (next non-LTS ROS release after Iron) and all Subsequent non-LTS release.
        • TODO: Draft a new plan going forward summarizing feedback.
    • [Lalancette | 20min] Discussion on Responding to REPS – Is this a TSC Task
      • REP are used to create standards within the ROS community - example is REP 145 -- Conventions for IMU Sensor Drivers (ROS.org)
      • They can also, potentially, be used for design documents
      • REP process is documented in REP-1, but pretty out-of-date
        • REP process has gone kind of moribund - unclear what the process is and who is responsible.
        • Open Robotics is going to revise REP-1 to bring it up-to-date.
      • Open questions:
        • Who is the final authority on accepting REPs? Should it be the TSC?
          • By unanimous straw vote ROS 2 TSC approves / rejects REPS.
          • Chris or a committee will review REPs and bring them to the TSC. Email will be sent out before the meeting.
          • Roughly the process is as follows:
            • Draft REP received.
            • Review committee works with REPs authors to iterate on draft based on feedback. We try to match a TSC member to be the REP proposers
            • TSC does final vote / resolves conflict. At this point the REP should be mostly complete.
        • TODO: draft a document covering REP process and bring it to the TSC [Technical Steering Cabal].
        • Should the TSC review open REPs as a regular part of this meeting?
  • Recurring business
3 Likes
2

The community?

At least that’s what I believe has been the case so far?

What was the main motivation for discussing this in the TSC?

3

I would like to temper this, slightly - I misremembered what release version the Rust Client Library was at during the Client Libraries Working Group meeting. We have in fact released version 0.2. The 1.0 release is still a ways off, we feel.

Sorry for the confusion!

1 Like
4

Just to clarify here, the main intent of this discussion was to determine how to increase the frequency and quality of REP reviews so REPs don’t languish in PRs.

My understanding is that current REP adoption procedure is that a benevolent dictator makes the final decision. The plan here is to have REPs reviewed by the TSC and then go to a final vote which is significantly more democratic.

@gavanderhoorn I would be curious if you have any feedback on how to increase community visibility into this process. One potential approach is that we post a REP discussion thread on Discourse ahead of the TSC meeting and have the community submit their opinions.

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.