I restate the post above. RPM alone isn't flexible enough to make an OpenACS distribution.
I think we read your first post, I think we simply disagree with it, at least in regard to how to distribute OpenACS on standard RedHat CD images. As a proof by counterexample, note that OpenACS is already distributed by Debian in package form, therefore it seems obvious that RPMs are flexible enough to make an OpenACS distribution (though some feel RH RPMs are less flexible than Debian's system, they're of roughly equivalent power).
If people port OpenACS to Perl, they can maintain their own distribution as a layer on our datamodel, if they wish to. We're very unlikely to support multi-language versions of OpenACS. If we did, we could simply release it as a separate RPM anyway.
As far as much of the rest of what you're talking about, on our site (openacs.org) we will maintain descriptions of modules, their release history, etc in the database, using the SDM, with code archived via CVS. When we speak of RPM distribution, we're speaking of a fixed cut of a well-defined release. Users who want to fish from contributed modules that haven't made it into the release, etc, can do so from openacs.org. The ACS 4.0 package manager will help ensure that version dependencies, etc are correct when the package is actually installed by the user. The necessary information will be stored in the database by the package manager describing each user's exact configuration.
We very likely will end up with (additional) volunteer coordinators to work with people who want to contribute modules, etc. Given that today's "coordinators" are volunteers and that OpenACS is gathering steam, it's almost a given.
To sum up, I think you may be confusing two separate issues, the first being "how do we manage the variety of versions, modules, etc which will grow as OpenACS grows", the second being "how do we cut fixed releases for Linux distributions that require them". Using the database and associated software modules to manage the first problem makes a lot of sense (and is why the SDM exists and why aD is writing the package manager for ACS 4.0), but not the second, IMO.
