search

ros-visualization / visualization_tutorials

Tutorials related to using and extending RViz and interactive_markers.
262 stars 263 forks source link

Catkinize groovy-devel #10

Closed danepowell closed 11 years ago

danepowell commented 11 years ago

This is just a backport of the catkinization from hydro-devel

hershwg commented 11 years ago

Thanks for the contribution, but I wonder why this is desired? Are you writing something that uses catkin which depends on these tutorial packages?

danepowell commented 11 years ago

Yes, I'm writing a package that makes use of interactive markers and the interactive marker tutorials. I don't know yet that I'll be able to release it publicly, but I wanted it to be catkinized.

hershwg commented 11 years ago

@dgossow do you have an opinion on this? I feel like it is out there and released already and this is a major change. On the other hand, maybe it doesn't affect much? Docs need to change?

dgossow commented 11 years ago

Usually, you shouldn't make a major change like this that late in the life cycle of a ROS release. I don't think that many packages depend on visualization_tutorials, but it's bad practice. Also, if you're not releasing the packages, you can as well just use them from source with the branch you already created, so I don't see the value of this when there's a danger of causing problems for groovy users.

dgossow commented 11 years ago

Maybe @tfoote, @wjwwood or @dirk-thomas will give us directions on how to proceed.

wjwwood commented 11 years ago

Is interactive_markers catkinized in groovy?

hershwg commented 11 years ago

yes: https://github.com/ros-visualization/interactive_markers/blob/groovy-devel/package.xml

wjwwood commented 11 years ago

I would say it is completely up to the maintainers, but @dgossow is right to have reservations about updating a package with a potentially breaking change in the middle of a released distro.

danepowell commented 11 years ago

It's up to you, I certainly don't want to make life difficult for anyone. But I think the only users affected would be those using visualization_tutorials from src (how many of those can there be?), and they'd just have to move the package to a catkin workspace. Anyway, I defer to your judgments :)

tfoote commented 11 years ago

For development I'd suggest just using the hydro branch, as this is basically a backport of the hydro branch. And then targeting a potential future release against Hydro.

dgossow commented 11 years ago

I'd say close. If this blocks you from releasing something into groovy, we'll reconsider.