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

[Leif Christensen]

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