Closed ugocupcic closed 9 years ago
I will closely follow that topic (see email)
Here's what I could think of - based on @guihomework suggestions:
@guihomework I addressed @toliver comment (directly edited my comment with the list above). We discussed it internally and the proposal above makes sense to us. I'll probably start on this in the next few days, once you tell me your feeling about this.
Cheers
This split suggestion looks quite nice to me but could have small adjustments :
cheers
Hi @guihomework,
Thanks for the great input. I just wanted to clarify something regarding sr_high_level_interface (I rather like sr_interface, will probably update the name). We are aiming for this to be the new recommended way of interacting with the hand (for those who aren't power users). That's why the commander is in there. sr_interface is basically the minimum amount of stuff you need to get the commander (+ examples etc...).
The scenario we want is for "normal" users to install everything up to sr_interface. They could also look into sr_tools if needed (as you said sr-contrib is there for legacy reasons, the good stuff from contrib will be migrated to sr_tools). Then power users could get away with installing common and core - if they don't care about moveit / easier to use interface. Finally someone that just wants to interact with a hand from another computer simply needs to install common.
Good point for sr_self_test (it's not needed for gazebo anymore since we got rid of the gazebo plugin, did you see @AndriyPt's pull request?). I'll migrate it to sr_core.
Regarding your generic hand moveit config, the goal is to get it into sr_core once we have a proper way of merging the configs. I might put it in sr_tools for now. Hand_kinematics needs to go in sr_interface since it's needed for moveit / commander.
Regarding sr_robot_msgs, I'm not convinced that having a dependency on moveit_msgs (you don't need the whole of moveit for that, but you do need a bunch of msg packages which are quite small) is more problematic than creating another package somewhere else. In the scenarios I listed above, if you want to install with our hand from a remote computer, the only thing you need to install is the common meta package. That wouldn't be true anymore if we moved those out.
I'll add the updated list in a separate comment right after this.
Cheers,
Updating the splitted packages based on the discussion:
Hi, This restructuring + explanation are fine.
Regarding sr_gazebo, I had seen that, but no change to test it yet. We diverged from sr-ros-interface. I wanted to merge all your changes back and I hoped the UR dependencies would go away to not need that.
With this split this goes in the direction we need since only sr_common and sr_core will be required.
The question, is : Should I merge sr-ros-interface with our ubi-agni repository first and then merge the split, or try to cherry pick our changes to put them separately on the new repositories (our changes are mainly on the sr_core in sr_description) ? I feel both will be complex anyway. Any suggestion ?
As you said both will be complex. What seems like the easiest solution would be (if you don't mind loosing the history) to do it package per package once the split has been done? (a brutal diff on the folders if you see what I mean)
Oh, you mean you are not splitting your repositories, just creating new ones with an initial commit at the time of the split ?
No no we are splitting the repositories etc... I meant that it might be easier for you to do it that way?
Ok, then I think I will rebase my changes on the few packages after the split, helping the rebase by pointing the correct commit (in case the history is kept but history is rewritten).
Started to work on this in this branch
Keeping only the core stacks in that one as discussed multiple times internally and with @guihomework