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 15:19:47 GMT
Graham Leggett wrote:
>> 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.

Exactly my point.  This is what sandboxes are for.  Not production.  You
argue that this produces good results.  So let's take one bug...

   ASF Bugzilla Bug 16696 Errore Windows Xp with Cache
   Opened: 2003-02-03 11:26

   When I set the directives how the manual say:
      CacheEnable disk /
   I continuosly have a Window error message (Si è verificato un errore
   In Apache HTTP server. L'applicazione verrà chiusa: It was an error
   on Apache HTTP server. The application will be close).

So let's see what was done...

   Additional Comment #1 From Paul Querna  2005-06-03 02:47

   Can you please try this with 2.0.54?

This was productive?  No 'need info', or 'what does your error log say?'
or 'what happens if...?' questions for over two years?

This isn't the audience we need 'testing' experiments; the simple fact
is that there is no 'community' outside of the devs to handle this.  If
you hack at an 'experimental' module, are you willing to subscribe and
handle users@ to guide them in YOUR experiment?

I'm not suggesting we will get everything right from the starting line.
But until the module is useful, it doesn't belong in svn, but inside
a sandbox.  And once it is useful, it belongs in trunk.  Then if the
authors, or others, are still dubious about it's behavior, we should
decide if (like perchild) it's beyond redemption for the coming release,
and just defer it for the next release.

>> 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.

And we learned that users, even with big warnings (hmmm... does perchild
sound familiar?) expect our code to work, at least, do something useful.

In fact, perchild proved WHY we should not do this.  It -was- in the 
tree and yet it also did not exist.  All we gained from perchild was
ill-will twords us, the developers and foundation.

Experiments are only useful while someone is willing to stand behind
them.  Here at the ASF, 'someone' means at miminum, a small core of

cache attracted developers (as you observed above) and so was a success
in the release tarball, but managed to piss off alot of users who had
grabbed 2.0 expecting to be able to deploy a caching proxy without all
that much trouble.  perchild lost it's appeal and never evolved, pissing
off many more users and spawning competing forks of a multiple-user,
multiple-vhost worker MPM models.

I don't mind rolling dice that the code is 'good enough' if it gets the
votes here on list.  Seriously, no objections.  But it's too damned easy
to get +1 "ya, that's a cool new module, but I doubt it works, so throw
it in experimental."  Code that, anywhere else in the ASF, would never
get the votes for release.  And -that- is why experimental must die :)


View raw message