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

[Steffen Planthaber]

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