httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Issues for 2.1.8
Date Wed, 21 Sep 2005 08:39:11 GMT
William A. Rowe, Jr. wrote:

> Please don't confuse my weeks of effort, originating from my manual
> inspection (not automation) of the 'unusual' traffic patterns, combined
> with third party observations in the security community, with any
> detailed review of mod_proxy as a whole!  If you believe that I've
> had a major impact on the stability or quality of the entire proxy
> framework you are demonstrating that you truly don't know 5% of the
> lines within the proxy module and are entirely ignorant of the many
> complaints in our bugzilla w.r.t. various specific behaviors.

I was the one who rewrote proxy for v2.0, and coordinated a lot of the 
early bugfixes to it before moving onto the LDAP stuff, after which 
others took over proxy. I think I still know that code well enough to 
know that it works.

> The problem is that cache in 2.0 never worked at all once it 'filled up'
> - showing the author truly never took the module through it's paces.

Cache was built from scratch in the source tree in the experimental 
directory, and is only nearing completion now. Cache has had many 
authors during it's stay in the experimental (and now cache) 
directories, so to say "the author never took the module through it's 
paces" makes no sense whatsoever.

> Yes, yes, yes!!!  Now let's discuss incubations processes - in yet
> another thread unrelated to general availability release  - and find
> the way that 'cool new stuff' will truly be tested, fixed and finally
> brought into the core :)

Why?

We already have an incubation process. If that process has flaws, lets 
fix those flaws.

If the flaw is that --with-foo doesn't show the experimental status, 
then lets update the comment for that module in ./configure --help to 
say "experimental". Beyond that it's user beware.

> So let's engage Mr. Temme and his idea of a CPAN-ish modules facility?

We already have a basic one (modules.apache.org). While a CPAN-ish one 
may be a better modules.apache.org, it still does not fix the perception 
that the tarball is "Apache" code, and modules/CPAN-ish is "external" code.

> The folks were thinking of a mechanism to bring in third party mods.
> But what about our own, experimental, somewhat unstable, or simply still
> moving target sandboxes, which keep growing new features too quickly?

If it's not in the tree, it does not exist. We have learned this from 
past experience.

There are 7 LDAP modules in modules.apache.org. The end user needs an 
LDAP module - in most cases where the use has general needs, the user is 
going to want to install the official Apache module, as they don't have 
time to evaluate 7 different solutions to their problem. But nothing in 
the list of 7 modules suggests that any of these modules is an official 
Apache one - why would the end user think that?

The majority of end users are going to experience httpd from a vendor 
supplied package anyway, and are going to use what their vendor installs.

Regards,
Graham
--

Mime
View raw message