search

CentroEPiaggio / kuka-lwr

Software related to the KUKA LWR 4+: for real and for simulation.
The Unlicense
101 stars 81 forks source link

ros_control API changes in Kinetic #72

Open miguelprada opened 7 years ago

miguelprada commented 7 years ago

There's been a change of API for hardware_interface::ControllerInfo in the kinetic-devel branch of ros_control in order to allow controllers to use multiple hardware interfaces. This change breaks the canSwitch and doSwitch implementations here.

The fix is quite straightforward, and I already made it in my fork, but it only makes sense to apply it in a Kinetic targeted branch. If you open such a branch I would be happy to open a PR with my proposed fix.

carlosjoserg commented 7 years ago

That'd be great to have already.

There has been no official release of this package in any distro, and furthermore, I never liked the devel-branch-per-distro thing so common in ROS-wise repos ;)

I'd tell you to PR in master directly, but there is this long-standing PR #46, which I'd like to merge before moving forward to meet newest dependencies... this way I can tag the latest commit before upgrading for the API change as indigo or alike.

So give me a few days to sort out what's missing to merge it so we can move on with this.

Thanks !

miguelprada commented 7 years ago

Sure, I'll add some more changes I didn't notice at first (i.e. canSwitch has been replaced by prepareSwitch in RobotHW), tag the commit with the required changes in my fork and wait for you to be ready.

About the development branches vs tags, don't you think keeping indigo as a live branch is better in case you ever need to backport other changes or even just do some bug fixing?

carlosjoserg commented 7 years ago

About the development branches vs tags, don't you think keeping indigo as a live branch is better in case you ever need to backport other changes or even just do some bug fixing?

You said the magic word, only if you are a believer of backporting, which makes sense for bigger software following LTS releases, like Ubuntu, or for critical or security issues, which it is none of these in this case, I think.

I believe it is better for people to add functionality or even fix bugs on top of the latest, otherwise you might end-up also cherry-picking stuff from people working on previous versions to newer versions, which is very error-prone. It is open-source, so anyone is free to cherry-pick back at his/her own risk on his/her fork if a fix or a functionality is needed while using the package in a previous version of the dependency set.

But as always, a lot of IMHOs, since it is a matter of development styles according to the project, which it is a nightmare anyway when dealing with dependencies, LTS, ROS, etc, etc ;)

carlosjoserg commented 7 years ago

I''ve given a bit of thought on the development style, I think something like this could be good:

devel

Plus the policy of only rebasing&merging in master as the unique development branch, and only cherry-picking back compatible bug fixes or functionality. For instance, for a new release on the latest, say kinetic_release, it boils down to a mere rebase, until a new ROS distro is supported in master.

This way I don't think one misses bug fixes and new features in the latest version. How do you see it?

miguelprada commented 7 years ago

Looks good to me.

That being said, I'm probably not the right person to vet this. My experience with git and release workflows is quite limited yet.

nstaub commented 7 years ago

Looks good to me, although I am also not the right person to vet.

carlosjoserg commented 7 years ago

Thanks for the input @nstaub !

And sorry for the slow response !!

I'm starting to move this...