[CMake] Call for Module maintainer volunteers

[Brandon Van Every]

On 7/25/07, Alan W. Irwin <irwin at beluga.phys.uvic.ca> wrote:
> On 2007-07-25 14:46-0400 Brandon Van Every wrote:
>
> > It also slaves the release cycles of unrelated modules to each other.
> > [...]
>
> True.  That is the whole point.  I believe the concerns you have expressed
> are the standard concerns for the release of any software package made up of
> different components, and I am not arguing that the module releases will be
> any different in this regard.  However, I do argue it is better for the
> modules to have an independent release cycle than the cmake core since that
> allows more coherent testing (e.g., of release 1.1.0) of the latest set of
> modules whose maintainers feel they are ready for such testing.

But at this time, I do not trust that volunteers are going to
comprehensively shoulder such coordinated work.  Kitware has some
revenues associated with CMake and they're not even doing it.  It's
reasonable for volunteers to tend to the versioning of their own
package.  It's not reasonable to expect them to function effectively
as a QA committee.

Since I have no faith in the quality and speed of a coordinated
volunteer release cycle, I don't see value in a separate CMake Module
version number.  I'll stick to whatever the official CMake version
number guarantees.

> Let's make this discussion more concrete by taking a specific example.  I
> have put together Ada language support for CMake. The requisite language
> support modules now work for three platforms, and it is obviously time for
> much wider testing. Currently, though, the Ada language modules are hidden
> away on the PLplot svn server.  It will definitely be a step in the right
> direction to get these modules into CMake cvs since that improves the
> chances they will receive some additional testing.

Yep.  That's what soliciting volunteers for module maintenance is all
about.  If they're not getting into CVS then they're not doing anyone
any good.

> However, as potential
> maintainer of those modules it would be a big step for me to recommend to
> Bill the Ada modules go into an integrated release of CMake without
> substantial widespread testing on a variety of platforms, and the cvs
> version may never get such testing.  (Other potential module maintainers
> have already expressed this concern today.)

Well, so?  Call me blase, but it's not like everything in CMake works.
 If you've done a lot of testing in your group, then there's a higher
chance that when they're put out into the wild, they'll work well
enough for a lot of people.  If they don't, hey it's open source and
you can do better next time.  Most of us are not getting paid for
this.  I'm making money on my CMake skills at present, but not for
shipping modules.  I'd go beef up the regex capabilities or the
documentation if I had all the time in the world, but I don't, and it
generates no revenue for me.  Kitware is under similar constraints of
ROI and that's why they ask for volunteers.  So in an open source
context, let's not overthink the level of service we're going to
provide to anybody.

> So having thought a bit more about this, what I believe we need is
> well-publicized, easy to use, on-going experimental releases of modules.

I don't want to deal with a variation on "DLL Hell" in a user's CMake
configuration though.  I think the bleeding edge people should build
CMake from CVS.  Or else projects should deploy their own modules as
part of their builds, if they want to use unofficial ones.  There's a
mechanism for loading a user module, although I haven't used it.


Cheers,
Brandon Van Every