[Vxl-maintainers] Informal VXL meeting at CVPR 2004

[Amitha P. <pe...@cs...>]

Folks,

A few of us met over lunch at CVPR a couple of weeks ago to talk
about VXL. Present were:
  Amitha Perera, Bob Kaucic (GE)
  Chuck Stewart, Matt Turek, Gary Yang, Brad King (RPI)
  Kongbin Kang (Brown)

The discussion primarily focused on the "core" versus "contrib" and
the creation of another category/directory, as Joe Mundy had
suggested in an email to this forum.

The key things that came up:

- The word "core" is ambiguous, and this ambiguity may be the cause
  of the previous discussion. To some, "core" meant "stable" (API
  stable, code well tested); to others, "core" meant "foundational".
  [ I think VXL intends "core" to mean "stable"; "level 1" means
  "foundational". ]

- We do need to get more code from "contrib" into the "core"
  directory. The current road is that the library should be
  documented, and at least one other group must okay it. We all
  agreed with this. However, it is not often clear what code in
  contrib is stable enough for other groups to use.

- We could label the libraries, regardless of which directories they
  happen to be in. Inventing the labels "stable", "stable-candidate",
  and "development", each library would be labeled by one of
  these. Top-level CMake variables will allow you to build the stable
  parts of the tree (all of "core" is stable); the stable and stable
  candidates (which adds some "contrib" code); or the stable, stable
  candidates and development parts (all of vxl).

- When a group is done with actively developing a library, they would
  document it, label it as "stable candidate", and inform the VXL
  community. This will allow other groups to start using the code
  knowing that the API is not going to change underneath them without
  group concensus.

- When another group uses and okays the library, it moves to the
  "stable" category, and the code moves to the "core" directory.

- There is a strict dependency order between the categories. "Stable"
  can only depend on "stable". "Stable candidate" on "stable" and
  "stable candidate". And "development" can depend on anything. There
  is, of course, always the restriction that the library dependencies
  are acyclic. Thus, to make a library "stable-candidate", the group
  must put the effort into making the dependencies also "stable-candidate".

- The documentation must include a high-level description (like a VXL
  book chapter) that will give the first-time user a good idea of
  what the library does and how the parts fit together.

For example, Chuck and I want to move rrel and probably rsdl to
"stable-candidate". Hopefully soon we'll write the required high-level
documentation. (The API is already well documented.) Another library
that come to mind are mul/vil3d.

Comments?

Amitha.