Hi, Am 08.09.2014 um 11:03 schrieb Leif Christensen: > 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.
+1 "external" folders mean to me "not maintained by rock developers" (exept making them build with autoproj by patches) > > 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". I also see Option 4 (which I prefer): - keep external/ with packages useful for different topics (kdtree, boost, etc.) but also have categorized external foldes to help finding these libs: like /planning/external/ompl > > 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". I think it should be visible in the folder structure if the code in a package is maintained by the community or by an EXTERNAL community/person Steffen > > 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 >> > -- Steffen Planthaber Weltraumrobotik Besuchsadresse der Nebengeschäftstelle: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 5 28359 Bremen, Germany Postadresse der Hauptgeschäftsstelle Standort Bremen: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 1 28359 Bremen, Germany Tel.: +49 421 178 45-4125 Zentrale: +49 421 178 45-0 Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen) 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
