This is kind of a follow-up to #955 (comment) and the discussion under #898, which has a bunch of reasons why tracking a tag has been the right choice for ros2_tracing so far. The first reason is that this is what we agreed on when we integrated & added ros2_tracing to the core repos last year. Now I'd like to ask to revisit that and switch to tracking a branch.

@jacobperron seems to think it should be fine, but I'll go over the couple points that @nuclearsandwich nicely summarized under #898 (comment) and propose solutions.

A major concern when reviewing a branch based inclusion was the fact that their change control process is not *exactly our process, that is, they don't run our official CI for each change. The problem is not resolved by independent CI.

One solution would be to give me access to ci.ros2.org so that I could run CI on all supported platforms. I was planning to add arm64 and Windows to our CI (RPi or Docker+qemu and AppVeyor), but it's time-consuming to set up and maintain, and ci.ros2.org can already do that.

The above concern makes it possible for a change to make it through an external review and automated testing process but still break our builds. And that compounds with the fact that as none of us are maintainers of the external project, we can't change the upstream in order to resolve the issue. Our only option for resolution is re-targeting either to an unreleased commit as in #899 or pinning back to a previously known good commit.

I've recently given "developer" access (GitLab permission) to some Open Robotics people. This allows those people to push to non-protected branches and review merge requests. By changing a setting it can also allow those people to merge MRs on/to protected branches, which would allow them to merge fixes if @iluetkeb or myself can't get to it quickly enough.

In general we're trying to keep dependencies tight and reliable. (Recently we even removed poco, an example in the earlier discussion of a widely used library, in favor of a more tightly scoped internal implementation of the needed features.)

I guess this point is more about confidence/trust in the maintainers, how reliable they are -- or have been -- and a bit about the nature of the dependency.

Even if ros2_tracing is far from being feature-complete, I think it has matured & stabilized.

Let me know what you think! I've opened #958 for the actual proposed change, but the conversation (if any) can happen here.