rosidl_typesupport_gurumdds not released in Rolling on Ubuntu Jammy

[nuclearsandwich]

The ROS 2 Rolling Ridley distribution recently migrated to Ubuntu 22.04 Jammy using the rosdistro migration tool.

This repository is one which failed to bloom during the migration because the gurumdds-2.8 dependency is not yet available in Ubuntu Jammy. Once the Jammy repositories and the rosdep database are updated it should be possible to release this repository in Rolling again by running bloom normally.

Packages which are not released in Rolling may not be automatically added to future stable ROS 2 distributions.

[nuclearsandwich]

@YoungJin-gurum does it make sense to deprecate the typesupport packages and make this a single-package repository containing gurumdds_cmake_module?

[YoungJin-gurum]

does it make sense to deprecate the typesupport packages and make this a single-package repository containing gurumdds_cmake_module?

You're right. I will proceed with package integration immediately.
It's much more efficient in terms of package management.

[YoungJin-gurum]

@nuclearsandwich What should I do with the typesupport package after merging gurumdds_cmake_module into the rmw_gurumdds package? Just mark this package as deprecated? Is there anything I should be careful about when releasing it in the future?

[YoungJin-gurum]

catkin_pkg version 0.5.1 has error about attribute, so I rollback to 0.5.0.

[nuclearsandwich]

@YoungJin-gurum the issue you hit was reported as ros-infrastructure/catkin_pkg#341 and should be fixed in an upcoming release. Sorry about that!

[nuclearsandwich]

What should I do with the typesupport package after merging gurumdds_cmake_module into the rmw_gurumdds package?

There are two overlapping questions that I see.

1. What to do in the source code for each repository: ros2/rosidl_typesupport_gurumdds and ros2/rmw_gurumdds?

The simplest thing to do would be to delete the rosidl_typesupport_gurumdds_c and rosidl_typesupport_gurumdds_cpp source directories from the master (and possibly humble) branches of this repository, rename it to ros2/gurumdds_cmake_module and then just continue from there.
A more sophisticated, but more complicated procedure could involve relocating the contents of this repository's gurumdds_cmake_module package to the repository root while still leaving it as a separate package and repository from rmw_gurmmdds.

The most sophisticated thing would be to use a tool like git-subtree(1) to move the gurumdds_cmake_module package from this repository to rmw_gurumdds and then you can just archive this repository and carry on maintaining all packages in rmw_gurumdds.

2. What to do for the released packages of rosidl_typesupport_gurumdds_c and rosidl_typesupport_gurumdds_cpp.

Just mark this package as deprecated?

Because the typesupport packages were never "wired up" in bloom's rosidl typesupport dependency insertion, they were never used by message packages in official the distribution binaries. The package.xml specification has a <deprecated> tag but I haven't seen it widely used and so I don't know which tools, if any, actually surface that information. An update to the repository's README.md before archiving it is probably sufficient.

Is there anything I should be careful about when releasing it in the future?

How to handle future releases will depend on the decisions above. If you move gurumdds_cmake_module to the rmw_gurumdds repository you won't need to release from this repository again and there is no special care needed.

Likewise if you delete the typesupport packages from this repository and just use it for releasing gurumdds_cmake_module then bloom will detect that only the gurumdds_cmake_module package is present and just release it.

If you decide not too delete the typesupport packages from master and just mark them as deprecated via a combination of README.md documentation and adding an AMENT_IGNORE file to the root of each package then you'll also need to add configuration to bloom to ignore those packages since bloom does not heed AMENT_IGNORE files.

Depending on which route you prefer to go I can provide more precise suggestions / instructions.

[YoungJin-gurum]

@nuclearsandwich Thanks for the detailed explanation.

I will choose the first, 'move gurumdds_cmake_module to the rmw_gurumdds repository'.
https://github.com/ros2/rmw_gurumdds/commits/master
In this case, is it okay to release only from the rmw_gurumdds package in the future?
And mark as deprecated via a README.md file of rosidl_typesupport_gurumdds?
I think it's much more reasonable to merge the gurumdds_cmake_module into rmw_gurumdds rather than leaving a separate repository.