First verify that this builds and resolves the CMake warning by building up-to tracetools.

I tried to scope this but the upstream and downstream was 244/298 packages and using packages-select with it overflows the command length buffer locally and I can't imagine CI would enjoy it. So here's full CI with the new tracetools changes

• Linux
• Linux-aarch64
• macOS
• Windows

The windows build hung during tests (ros2/build_farmer#248) but only after completing a full build.

Security failures with Connext on macOS are related to ros2/system_tests#409
cli tests in ros2cli packages were affected by ros2/rclpy#536 and other failing tests are flakey with work to improve them ongoing.

Why is the version a commit hash instead of the foxy or master branch? Are these branches too unstable?

Why is the version a commit hash instead of the foxy or master branch?

As @nuclearsandwich mentioned, I have to delay the Foxy release. I want to include some more things for the quality declaration, but I personally haven't had time yet (I blame school work 😛)

Are these branches too unstable?

Up until now we've always used release tags instead of branches to properly test ros2_tracing every time.

I'd argue that it's not "unstable" and definitely wouldn't mind switching to branches, but I can't run CI on all supported platforms, so that's that.

Hmmm... Even if it's not release-ready, I'd still rather use master so I can vcs pull to check for changes as they roll in, so long as it doesn't tend to break the build.

Before we used a tag because we don't want to track master and be exposed to any changes landing there and potentially regressing the build. That rational hasn't changed.

Sure, if master is unsuitably unstable that it may regress the build, can we maybe create a new ros2_tracing branch for ros2.repos to track that is slower moving so as not to regress the build? Your rationale applies to every package in ros2.repos.

Your rationale applies to every package in ros2.repos.

The significant difference that we don't have write ccess to tracetools. Any third party repositories like this we prefer to use tags / hashes or branches (if stable) over master.

we maybe create a new ros2_tracing branch for ros2.repos to track that is slower moving so as not to regress the build?

Upstream is planning to tag a new version soon (https://gitlab.com/micro-ROS/ros_tracing/ros2_tracing/-/merge_requests/163#note_321456164) and then we will use that tag (as we have done before).

Any third party repositories like this we prefer to use tags / hashes or branches (if stable) over master.

master does seem to be such a a fairly stable branch, and foxy seems to be a fine candidate as well. And if anything, master seems to adapt more slowly than many core ROS2 packages, which is not a problem that tags can solve. (in the latest case, the version bump was to fix a build problem, which should have been done with just a vcs pull rather than a vcs import)