-
Notifications
You must be signed in to change notification settings - Fork 34
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
Replace ros2/rmw_connext with rticommunity/rmw_connextdds #9
Comments
Based on this ticket - are you also planning to remove |
@emersonknapp Once we get everything in place, I think that's the plan. We still have to review these pull requests of course. |
👍 just trying to help make sure that list is complete - https://github.com/ros2/ci will need updates too |
@emersonknapp I plan on creating a PR for Once I create that PR, I'll likely need some guidance to make sure things look good, since I'm not sure how we will approach these updates (especially when it comes to making sure nothing breaks catastrophically :) ). In general you are right that all these changes will need to be coordinated with a timely update of the default I also modified ros2.repos to build the source tree with all the forked repos, which I've been using to test the changes using |
By the way, I realized one other thing. Once we merge all of these PRs and get a successful run on https://ci.ros2.org, we are also going to have to do a bloom release and get it onto https://build.ros2.org right away. That's because all |
I think that some of the PRs above are needed to make CI pass with I would first only merge the ones in the first group, which is going to make things easier IMO. PRs required to make
Nice to merge:
Only removing support for |
For sequencing - I would expect ^ to be the first step once it has been determined to work correctly. It seems to me that there is definitely an order of operations that results in nothing being broken, and without having to synchronize any of the events. From my perspective, that looks something like:
Much of the above consideration seems to be concerned with atomically replacing, rather than the above approach of adding the new thing, stabilizing, then removing the old thing. |
Thank you all for your input. I'd like to combine your suggestions, in that I think we could rank the PRs in order of priority, and do staggered merges, while also proceeding with a more incremental policy. Indeed all these PRs try to replace From your suggestions, I'd like to propose the following plan:
Does this sound reasonable and along the lines of what you had in mind? Please feel free to edit/add to the list. |
IMO, removing the old implementations from CI directly is fine.
The plan sounds perfect to me, @clalancette can you double check if this is fine? |
Yes, agreed. I think we should aim to completely replace Two additional items:
Other than that, the above plan looks great. |
I have made progress on several tasks (as reflected in the edited comment above). @clalancette can you help me complete the "blooming" and releasing of @ivanpauno can you help me progress the different PRs towards merging? Thanks! |
I think you've figured this out, since you successfully opened the PR. I've now fixed the name of the release repository under ros2-gbp, so you should be able to re-release there. Ping me again once you've re-opened the PR, I'll take a look at the release repository.
Essentially you can change the code on https://github.com/ros2/ci , and then there is a field in https://ci.ros2.org/job/ci_launcher/build?delay=0sec where you can specify the CI branch to use. Unfortunately, that only works for branches pushed directly to https://github.com/ros2/ci. I've gone ahead and created a new branch https://github.com/ros2/ci/tree/asorbini/rmw_connextdds ; when you think you have the fixes you want to the CI code, open a PR against that branch and I'll merge it immediately. Then you can run the CI job and test it out. Once we've figured out all of the changes necessary, we can squash them all together and do a proper review. |
I bloomed a new release (0.2.1), and opened a new PR with the
Thank you for the setup work, I'll try my hand at running with these changes and report back! |
Certainly one of those two things could be the problem. I don't really know since I wasn't involved in setting up
You can either do the "by-hand" method that I pointed out, or the docker method that @nuclearsandwich pointed out. Once you have things reasonably working there, I don't know of a further way to do testing except "live" on the buildfarm. So my suggestion is that you make things work for you locally, then submit a PR and merge it. Then open the rosdistro PR. The cycle time to test things out is a little slow, but numbers are cheap so it doesn't matter if it takes a few iterations to get it right. |
I tracked down why that was the case, and adding that flag seems to be recommended in the rti Connext 5.3.1 platform notes:
We're using newer gcc versions, so IDK if that's still needed or not. |
Yep, I was able to reproduce locally with @nuclearsandwich's instructions. I was thinking more along the lines of "is there a way for me to test the release process with a custom branch/tag of the repository so that I may make changes to the source repo and not have to regenerate the I think I'll do some tests with the "manual approach" that you suggested, and recreate an upstream tarball with modifications as needed. |
I think I found the issue! When building with Connext 5.3.1, the CMake helper function Setting I will push the change and re-bloom the repository to validate the fix (also re-run some CI tests to make sure the property works across platforms). EDIT: new PR for 0.3.1-1 |
It looks like it built! Woohoo! So here is a follow-up list:
We're getting close here! |
Good idea! I had noticed the
I did a local test, and the packages installed and ran a hello world talker/listener with no issue (including some basic command line tools, like
I opened a PR on ros2/ci.
Definitely starting to see "the light at the end of the One final note on the CI tests: I re-ran the plans (with my CI branch), and it seems like the failure in Here are the results from my latest runs: |
That one is new and started happening also with |
All right, I've merged and deployed the changes to CI. Here's a job with no current changes, just to make sure things are working as I expect: Here's a set of jobs with ros2/rmw_implementation#182 and ros2/ros2#1099 in place: |
OK, we have a lot of this in now. Here's what I think still needs to be done: Before freeze (April 5):
Ideally before freeze, but can be done after:
|
My 2 cents about merge ordering:
|
All of the failures in uncrustify were fixed by my latest commits in rclcpp, so that should go away. The only other failure was on Windows, but I think @asorbini knows about that one and is looking into it. I'm going to go back through the open PRs and respond to comments now. |
The failure is slightly different from what I've seen before, but it still seems related to "clock jitter" on Windows (so to speak). I'll investigate the specific test case further to confirm it, but I would assess the failure as "minor" for now. |
@clalancette thank you for transferring the repository to the Here's some "follow up" items:
Q: should I run bloom again to generate a new release? (0.3.1-3, I still have a few things to verify before going to 0.4.0) |
One more CI with all of the things that have been merged, plus the changes in ros2/rcl#903, ros2/rclpy#698, and ros2/rclcpp#1595: |
No, it shouldn't be necessary. It will all just be in place for when the next release gets done. |
All right, all things on the various lists here have been completed. In my opinion, this issue can be closed. @asorbini I'll let you do the honors. |
Haha, thank you @clalancette, appreciate the opportunity. I wouldn't have taken it personally though, I'm just glad we achieved this milestone 🎉 🎉 🎉 |
Signed-off-by: Michael Carroll <michael@openrobotics.org>
This issue tracks several PRs aimed at switching the RMW implementation for RTI Connext DDS included in the ROS2 source tree from the one provided by ros2/rmw_connext (
rmw_connext_cpp
) to the one provided by rticommunity/rmw_connextdds (rmw_connextdds
) in preparation for the ROS2 Galactic release.rcl #895
rclcpp #1574
rclpy #698
rmw_implementation #182
rosbag2 #671
rosidl_python #127
rosidl_typesupport #106
sros2 #253
system_tests #463
demos #489
ros2 #1099
This ros2.repos can be used to build the source tree using forks of all affected repositories.
The text was updated successfully, but these errors were encountered: