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

[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