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