Hi, I agree that the undecided/free-floating state is the maximum annoying one.
In the past I somewhat had the impression, that packages under external/ are really external, meaning untouched by Rock developers and often directly originate from an external VCS. Than there are manually copied external SDKs/etc. often nearby own code (camera_prosilica?), sometimes with slight modifications or glue code. Most important for me is a coherent directory structure and to see at a glimpse, if a package has external origins, mainly to get a clou, if the external code is kept up-to-date. So I see 3 options: - keep external/ with flat structure - add hierarchy to external (external/drivers, external/slam,...) - move "external" packages to same places as "internal". Since hopefully the rock community will grow and get more heterogeneous, the differentiation between internal and external seems obsolete, so I am going +1 for move "external" packages to same places as "internal". If that is too much work, I would vote for flat external (since the number of packages in there is currently not overwhelming and I like flat hierarchies). And +2 for announcing, if there has been a decision and how this is handled from then on... LG, Leif Am 07.09.2014 um 21:21 schrieb Sylvain Joyeux: > 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 > -- Leif Christensen DFKI Bremen Robotics Innovation Center Robert-Hooke-Straße 5 28359 Bremen, Germany Phone: +49 (0)421 17845-4149 Fax: +49 (0)421 17845-4150 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
