[Rock-dev] Decision on the fate of external/ ?

Mon Sep 8 10:06:40 CEST 2014

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
> Rock-dev at dfki.de
> 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: robotik at dfki.de

  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
  -----------------------------------------------------------------------