Lots of good points here. I look at MoveIt! similar to PCL, OpenCV, and the navigation stack - all which are centralized under one repo. If companies like Google can maintain their vast amount of software on a single repo, it seems like our modest MoveIt! can also. I understand there are corner cases that might require manually pulling out a package, but I don’t think they warrant the drag it has caused on the agility of the MoveIt! project’s progress.
they’ll need to install rviz (for example), which will in turn install a ton of graphical dependencies. This is not good on a robot that may be running ubuntu server
As you mentioned, simply add CATKIN_IGNORE, delete the folder, or using catkin-tools’ blacklist feature
consider separating the moveit_ros repo from the ROS-independent components
moveit_core was suppose to be ROS agnostic, but it in fact does have ROS dependencies such as ROS Time, ROS Package, ROS Console, and lots of ROS messages. I also believe no one is using it outside of ROS, so why should we waste so much developer time maintaining this separation?
I’m not sure that we can target this for a Kinetic release
We are going to be using Kinetic until 2021, so if we don’t target it we can’t really migrate because of the need for backports, etc. Considering Kinetic is not released yet, and even if it is we can still switch over, I think we should try our best for it.
How often did you observed changes across the different repos in the past?
Many times. Many of the features MoveIt! lacks require deep architecture changes across, at minimum, moveit_core and moveit_ros. For example: “KinematicsBase changes” required these PRs:
Even something as simple as upgrading to Eigen3 requires me filling out many many PR pages across MoveIt!
git clone takes much longer even if someone just wanted a single package
I believe almost everyone who builds MoveIt! from source already downloads all the separate repos per the Quick Start guide, so it shouldn’t change the download time, right? Of course if our repo gets too big we could delete some of the history.
releasing and building a subset of packages is more of a hassle for meta-packages