Last try. We've had the discussion about the desired fate of external/ twice already. It is time to get a formal vote on it. The current non-policy makes finding packages seriously annoying. I've been looking for planning software recently, started thinking that sbpl was not there only to find that it was indeed there ... in external/
Pro-external ========= Janosch and Matthias expressed that they feel we need to separate the "Rock packages" from the "non-Rock packages". That's what external/ is for. Under this circumstances, the following packages should be moved to external/ drivers/aravis drivers/phidgets drivers/gsf drivers/aria control/urdfdom control/urdfdom_headers control/reflexxes data_processing/openann planning/openrave control/kdl image_processing/viso2 image_processing/libelas slam/pcl slam/ceres_solver slam/flann slam/g2o slam/mtk slam/gmapping slam/octomap slam/hogman Con-external/ ======================== external/ is a non-category. While we elected to use categories try to make browsing / finding software easier, external/ by definition breaks this. Changing it would require renaming: external/sbpl => planning/sbpl external/ompl => planning/ompl external/freenect => drivers/freenect external/yaml-cpp => tools/yaml-cpp external/tinyxml => tools/tinyxml external/gdal => slam/gdal external/libply => slam/libply external/cminpack => ? (math) external/kdtree => ? (slam/kdtree ?) external/box2d => ? (2D physics engine but Janosch does not want it in simulation/) external/lemon => ? (graphs) external/snap => ? (graphs) external/gexf => ? (graphs) external/aruco => ? (augmented reality) One additional pro "argument" I've been countered with is that "we don't know how to categorize package X, so let's put it in external". When you see the non-categorized packages above, I believe that finding them a proper category would be a lot more constructive (because otherwise you mean that e.g. augmented reality or graph algorithms do not have their place in Rock). Under the Pro proposal, 1/3 of all the non- packages in the Rock package set should be in external/. Given that we categorize for the express purpose of making finding software easier, that sounds like not such a great situation. Moreover, for Rock to strive, we should reuse as much as we can (meaning that this proportion should definitely go up, not down). In the end, don't look for drivers in drivers/, look for them in drivers/ AND external/. Don't look for mapping software in slam/, look for slam/ AND external/. You get the picture. Finally, I personally feel that if we want to scale up and foster collaboration, having a policy like this one sounds like "either you are with us, or you are "external"". Sylvain _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
