On 7/25/07, Alan W. Irwin <[EMAIL PROTECTED]> 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
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
