The ROS 2 TSC is considering creating a new working group focused on client libraries. This post is to gather feedback and gauge likely participation. Please review the proposed working group’s description below, and post any comments you have in reply.
Description
The Client Libraries Working Group is responsible for the management, design and development of the foundational ROS 2 client library, rcl, as well as the “core” client libraries as determined by the ROS 2 TSC. Currently these are rclcpp and rclpy. The working group discusses new feature design and triages contributions, including discussing controversial pull requests with the goal of resolving discussions and moving those pull requests towards acceptance.
Leaders
Scope of work
- Design of rcl and “core” ROS 2 client libraries
- Management of rcl, “core” ROS 2 client libraries, and relevant supporting libraries
- Discussion and selection of design and task priorities, under the guidance of the TSC
- Pull request triage
Repositories responsible for
- rcl
- rclcpp
- rclpy
- rcl_interfaces
- rcl_logging
- spdlog_vendor
- rcutils
- rcpputils
- rpyutils
- examples
- demos
- Other client libraries when accepted (by white ballot or vote) as being part of the scope by the TSC
Something that needs thinking about is the relationship between this and the Middleware WG, which currently is doing some stuff relating to executors, which is arguably a client libraries thing but also has closely-related middleware aspects. Personally I would separate the working groups at the rmw/rcl interface boundary, with cooperation when it makes sense (e.g. executors), giving these repositories to the Middleware WG:
- rmw
- rmw_connextdds
- rmw_cyclonedds
- rmw_dds_common
- rmw_fastrtps
- rmw_implementation
- rosidl
- rosidl_dds
- rosidl_defaults
- rosidl_python
- rosidl_runtime_py
- rosidl_typesupport
- rosidl_typesupport_fastrtps
This gives a clean break between “uses RMW” and “is RMW”