Split this repo and deprecate robot_model
sloretz opened this issue ยท 21 comments
Summary of meeting:
Original issue: collada_urdf depends on geometric_shapes which depends on octomap. During the ROS Lunar release packages depending on packages in robot_model were blocked needlessly by the release of octomap and geometric shapes.
Plan
Before Lunar release
- Leave the metapackage robot_model in this repo, but re-release to lunar with status end-of-life with EOL message indicating other packages have been moved
- Update ROS Lunar migration notes on ROS wiki to say robot_model has been deprecated
Anytime, but sooner rather than later
- Move collada_parser and collada_urdf together to a new repo (#197 #198)
- Move kdl_parser and kdl_parser_py together to a new repo (#201 #202)
- Move joint_state_publisher to a new repo (#218, #219)
- Move urdf and urdf_parser_plugin together to a new repo (#222, #223)
- Add a README for this repo which points to the new repositories
Before M Turtle
- Add a new rep like REP-142 that lists each package independently in the robot_metapackage instead of robot_model (ros-infrastructure/rep#144)
- Don't release robot_model metapackage into ROS M
note to self: https://discourse.ros.org/t/repository-consolidation-moving-released-packages-to-another-repo/327/4
@clalancette @mikaelarguedas @wjwwood Does this look right?
Closing in favor of https://osrfoundation.atlassian.net/browse/ROS-38
I think it can be split into categories based on what needs to happen by when:
- Before Lunar Release (ideally before Beta):
- Leave the metapackage
robot_model
in this repo, but re-release to lunar with status end-of-life- Make sure the EOL message indicates that the
robot_model
metapackage is deprecated, the other packages have just been moved.
- Make sure the EOL message indicates that the
- Update ROS Lunar migration notes on ROS wiki
- Mention that the robot_model metapackge has been deprecated
- Leave the metapackage
- Any time, but sooner than later:
- Move
collada_parser
andcollada_urdf
together to a new repo - Move kdl_parser and kdl_parser_py together to a new repo
- Move joint_state_publisher to a new repo
- Move urdf and urdf_parser_plugin together to a new repo
- Add a README for this repo which points to the new repositories
- Move
- Any time before M-Turtle
- Add a new rep like REP-142 that lists each package independently in the robot_metapackage instead of robot_model
- Don't release robot_model metapackage into ROS M
Also, I think might be useful for these to be on GitHub since Jira is not public.
@sloretz it should be fine to have the overarching issue in JIRA as long as the individual issues are in GitHub, though I do still think having an organizing issue in GitHub helps with cross-referencing for external observers.
Edit: (I was just clarifying why I asked for it to be left open here, you don't need to change anything else)
๐ lgtm
@bmagyar FYI, thanks for reporting the issue
๐
Step 1 in ros/rosdistro#14675
Migration notes updated for lunar http://wiki.ros.org/lunar/Migration
Ideas for new repo names?
- ros/collada_model
- collada_parser
- collada_urdf
- ros/kdl_model
- kdl_parser
- kdl_parser py
- ros/joint_state_publisher
- joint_state_publisher
- ros/urdf_model
- urdf
- urdf_parser_plugin
@mikaelarguedas if these names look ok or if you've got better ones would you mind forking robot_model into them? I don't have the permissions needed to create a repo in the ros org.
My initial reaction is that the _model
isn't always necessary, though I don't feel strongly about it. I would have done:
- ros/collada_urdf
- because collada_urdf is the important package, and collada_parser is a means to an end imo
- ros/kdl_parser
- this seems to fit better (to me at least) than
_model
which doesn't seem to have anything to do with the package names within the repository
- this seems to fit better (to me at least) than
- ros/urdf
- urdf_parser_plugin is part of urdf in my mind, so urdf seems appropriate
- if I consider what
_model
means when attached tourdf
I can't come up with a meaning that tells me more than justurdf
These are all just suggestions. I think whatever you do will be just fine.
collada_urdf
and collada_parser
are now at https://github.com/ros/collada_urdf
Self note: Here were the steps to move a package from one repo to another
- Create the new repo (ex: https://github.com/ros/collada_urdf)
- Using the github GUI create an empty repo
- Checkout the current repo
- add a git-remote for the new repo
- push the desired branches to the new repo (ex: indigo-devel, kinetic-devel)
- Create a new release repo (ex: https://github.com/ros-gbp/collada_urdf-release)
- initialize it with an empty README
- Release the packages from the new repo
- catkin_generate_changelogs won't work. Add the
Forthcoming
bit to the changelogs manually - catkin_prepare_release works as usual
- bloom-release works up to the point of opening the rosdistro PR
- bloom-release will prep the release repository then close after an assertion about a duplicate package in the distrobution.yaml fails
- Manually create a PR to update the distrobution.yaml for each rosdistro. The PR should add the new repo and remove the moved packages from the old repo.
- catkin_generate_changelogs won't work. Add the
- Delete the packages from the source repo
Example of what the resulting rosdistro PR looks like: ros/rosdistro#14899
If all this was done, why am I getting this install conflict with ROS Lunar?
The state of URDF code locations was already complicated before this split - could you please document these changes on the URDF wiki similar to how I attempted to do so in 2013 here? Its amazing to me how many robotics projects (non-ROS, private) around the world use URDF, yet how messy it is to use.
The source for the diagram I made is here
Thanks!!
hello (?)
some packages still pull in robot_model/collada_parser
I deleted the */collada_parser
folders in src
, devel_isolated
and build_isolated
run rosdep update
, regenerated the .rosinstall
file, run wstool merge
but wstool update
continue to redownload robot_model/collada_parser
and then causing conflicts at build time
how can I fix?
All of the work for this is now merged (mostly thanks to @sloretz , thanks). I'm going to close this ticket out now.
@clalancette should follow-up issues be opened for the comments that came up on this issue during refactoring ? (e.g. #195 (comment))
@clalancette should follow-up issues be opened for the comments that came up on this issue during refactoring ? (e.g. #195 (comment))
Good idea, I've opened up #224 to track that issue.