Mads Toftum wrote:
On Tue, Sep 20, 2005 at 10:58:16PM -0500, William A. Rowe, Jr. wrote:
Because --with-foo / --without-foo syntax gives **NO** indication to
the user, or indication from the user, that they are willing to use
experimental code.
So your concern is not really that the modules are there, but rather
that they're not clearly marked as experimental?
* /modules/experimental/ is not a helpful layout, the modules belong
within their functional/behavioral choice of /modules/footype/ dirs.
Jim's proposal of modules/experimental/foo/ v.s. modules/stable/bar/
makes alot of sense.
* what do we gain from the 'experimental' designation? I've already
aruged not to ship unstable code in a GA. What if we added the
experimental placeholder, and a second 'experimental' tarball if we
want users to pick up all the experimental/new modules? This could
include other httpd subproject modules, as well, and fit into Kevin's
comment that some users just want to peek behind the curtain and
see what is coming up.
* ...but I'm not sure we even agree on what experimental actually
means. I'm not even sure there is agreement between the members
of the 'ship experimental modules in our releases' croud. Let's back
up and define it? I'm guessing there are more than one class of
'experimental' modules ...
Then how about grouping the modules in an experimental section of --help
output? Or to take it even further, perhaps a --enable-experimental
flag?
If we had a worthwhile definition of 'experimental', I'd be +1, but I'm
not sure experimental is the phrase we are looking for.
I'll toss up an example. /examples/ modules should be exactly that,
worthless in a running server, but providing documentation by example.
Hmmm... perhaps these belong somewhere in the TL /docs/ tree instead?
What about bucketeer and other production-useless, but test-useful
modules? Perhaps --with-tests would be good to enable these rather
than suggesting they are experiments?
Bill