Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ros2component fix to Dashing? #337

Closed
pbaughman opened this issue Sep 23, 2019 · 5 comments
Closed

ros2component fix to Dashing? #337

pbaughman opened this issue Sep 23, 2019 · 5 comments
Assignees

Comments

@pbaughman
Copy link
Contributor

Hey guys,

We're on 'Dashing' but our CI is blowing up a lot with an issue that I believe was fixed in PR #322 Would you guys consider cherry-picking this fix to the 'dashing' branch so we can get it without having to take the other ~35 commits in between? It looks like it cherry-picks cleanly, and the tests pass on the nightly docker.

Thanks! Feel free to close this issue if the answer is 'no'

@jacobperron
Copy link
Member

jacobperron commented Sep 23, 2019

#322 depends on ros2/rclpy#413, which depends on ros2/rcl#492.

ros2/rcl#492 adds a macro and changes the possible return value for several functions.
I believe everything is API/ABI compatible, so I think we could backport the three PRs in question.

@jacobperron jacobperron self-assigned this Sep 24, 2019
@jacobperron
Copy link
Member

jacobperron commented Sep 26, 2019

I've started looking at doing the backport, but it's a bit larger than anticipated. The necessary changes actually touch the RMW layer:

And there are some conflicts with another addition to RMW ros2/rmw#179.
The conflicts are not that difficult to resolve, but if I go forward opening a series of backport PRs I think they deserve close attention so we don't accidentally break things.

Possibly a less risky approach would be to backport an earlier iteration of the fix (bd6cef2), where we catch a generic RuntimeError instead of the new NodeNameNonExistentError that was introduced in the PRs I've listed above.

@hidmic @dirk-thomas @ivanpauno What do you guys think?
I don't mind doing the more invasive option, backporting the new error code, if you think it's acceptable.

@dirk-thomas
Copy link
Member

I don't think backporting this change is worth that amount of work and potential for regression. I am ok with implementing the previous hack / wildcard-exception-catch on the Dashing branch.

@ivanpauno
Copy link
Member

Yes, I was going to start backporting this until I realize that the amount of dependencies were huge.
The complete list also includes ros2/rcl#499 ros2/rcl#498.

Also, I don't think that adding a new return code and a new exception is API compatible. IMO, it breaks API.

Implementing the wildcard-exception-catch on Dashing branch sounds like a good idea to me.

@jacobperron
Copy link
Member

Thanks for your feedback, I've opened up a backport for the wildcard-exception-catch: #342

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants