With https://github.com/ros-tooling/metrics_statistics_msgs/pull/1 merged, we have one dependency of Topic Statistics in this new repo. Adding it to the ros2.repos file.

@wjwwood @thomas-moulard please take a look!

Should we wait to add the other library's repository?

We spit it into 2 PRs so that once we merge this we can run CI easily for the other one. libstatistics_collector(#897) depends on metrics_statistics_msgs (this PR).

@jacobperron could you please start CI for this PR?

Never mind, found the correct params to start the job.

• Linux
• Linux-aarch64
• macOS
• Windows

Package only CI:

• Linux
• Linux-aarch64
• macOS
• Windows

Interfaces which are being used by the client libraries are defined in rcl_interfaces. Why should we introduce a second package which becomes a dependency of rcl (currently rclcpp but clearly it will need to be pished down into rcl in the future)?

Interfaces which are being used by the client libraries are defined in rcl_interfaces. Why should we introduce a second package which becomes a dependency of rcl (currently rclcpp but clearly it will need to be pished down into rcl in the future)?

Hi @dirk-thomas: the dependency was introduced in this rclcpp PR (ros2/rclcpp#1050), where metrics_statistics_msgs is an rclcpp dependency. We discussed this offline with @wjwwood and we came to the conclusion that introducing the dependency as a separate repo (via https://github.com/ros-tooling/aws-roadmap/issues/249) was fine, with another reason being Topic Statistics is currently a C++ feature only.

another reason being Topic Statistics is currently a C++ feature only.

Obviously that is only a short term state. As soon as possible the feature will be pushed down into rcl in order to provide the same statistics in other client libraries like rclpy. And at that point I question the decision to have two interface packages: rcl_interfaces and something containing interfaces for rcl but with a different name. Imo it goes against the rational we settled on to create rcl_interfaces in the first place.

I also advised putting this logic into rcl as the statistics feature isn't nearly as useful if only part of your system can contribute to it. I think this is a result of not having time to push it down. When this is a feature of rcl, I agree it would make sense to put it in rcl_interfaces. I would also support putting the new messages in rcl_interfaces now, to be honest. I just didn't push the point.

Lets not create a Foxy-only message package then but move the interfaces into rcl_interfaces now. That makes sure that code using them doesn't have to be changed / broken in G-turtle.

Sounds good to me, @dabonnie can you guys do that then? Sorry for the back and forth.

We don't have a plan to add topic statistics to rclpy yet, but I agree that in the long run having the messages for it in rcl is the right thing to do.

We will close this PR and move code from metrics_statistics_msgs to rcl_interfaces.

Opened ros2/rcl_interfaces#98. @dabonnie we can close this.

Hey @dirk-thomas and @wjwwood can you please review ros2/rcl_interfaces#98? I'll close this given the PR in rcl_interfaces.