On 07.09.2014 21:21, Sylvain Joyeux wrote: > 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"".
In general i don't like the idea of "you are not with us" much, but i don't like the idea of putting all i "drivers/" too. We have several packages in drivers/ or external/ which does not belong there too. The Problem i have with some packages like "gdal" is that there are neither a driver nor a "slam/whatever". Another problem is "aravis" aravis is a library that is needed by the camera_aravis driver, which is needed by drivers/orogen/aravis. So we need to have three packages in drivers/ (and drivers/orogen) to get a camera aravis camera running. Which might also end in some confusing setups. Therefore external makes sense for me, we supporting the camera by integrating it in our camera_aravis package..., otherwise we need to to the same magic like for the prosilicas which i don't like either. It's really hard to take a decimation here because as you already mentions some packages could not really sorted into categories (like gdal/yaml), putting them in tools/ makes no real difference for me, pcl/kdtree yould also be only a "tool", kdtree could be used for image processing too for example. I thing we should find a way to handle packages that are purly downloaded and build by rock (maybe patches), and handle them separately. Therefore was the external folder, but maybe we add something like dirvers/external slam/external to make the separation better, this would solve the problem with aravis and a crouwded external/ meta folder. For the categorization we should discuss this per package, maybe we can add symlinks if a package belongs to several categories? Best, MAtthias > > Sylvain > _______________________________________________ > Rock-dev mailing list > [email protected] > http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev -- -- Matthias Goldhoorn Unterwasserrobotik Standort Bremen: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 5 28359 Bremen, Germany Phone: +49 (0)421 218-64100 Fax: +49 (0)421 218-64150 E-Mail: [email protected] Weitere Informationen: http://www.dfki.de/robotik ----------------------------------------------------------------------- Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973 Steuernummer: 19/673/0060/3 ----------------------------------------------------------------------- _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
