From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Thursday, September 06, 2001 2:56 PM
> On Thu, Sep 06, 2001 at 02:49:56PM -0700, Ryan Bloom wrote:
> > If the module is a part of the server, then it must work before the server
> > is production ready. You can't have a module that doesn't work in a server
> > that is going GA, it doesn't make sense. You will find if you read the
> > archives, that we have cancelled releases in the past, because a single
> > module did not work correctly. Anytime you put something into the core,
> > you take the very real chance of delaying the core server.
>
> I thought that we didn't follow the policy with certain modules.
> AIUI, mod_ssl is exempt from this. Why not mod_gz as well? Or, as
> some have suggested - stick it in modules/experimental?
mod_ssl is not exempt from this. It was decided over a year ago that ssl should
be supported in Apache 2.0, and about a year ago that became possible due to
relaxation of the crypto export regulations for open source within the US.
The mod_ssl will _not_ be unsupported or incomplete when we go GA. The fact is,
mod_ssl itself was a very stable piece of code. It has undergone a facelift in
conversion to 2.0, and this is far more likely to expose our existing 2.0 bugs
than introduce new bugs from mod_ssl.
> I'd also like to point out that no one has said that the module
> didn't work as expected. I tested it before I submitted it with
> my +1. If it doesn't work, it'd be fixed.
If it's stable and works, but clearly isn't a 'known quantity' in production
servers, it must land in modules/experimental until it's interaction with the
many clients is well understood. Compiling isn't the issue, usability is
(just like mod_auth_digest back in the 1.3 tree.)
