httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Issues for 2.1.8
Date Wed, 21 Sep 2005 14:55:05 GMT
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?


View raw message