httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Issues for 2.1.8
Date Wed, 21 Sep 2005 23:45:05 GMT
William A. Rowe, Jr. wrote:

> Exactly my point.  This is what sandboxes are for.  Not production.

Sandboxes are for refactoring. An entire sandbox for a single feature 
like a module is like hammering in a nail with a sledgehammer.

experimental/ is a sandbox for small well defined features where running 
a separate sandbox is overkill.

> 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).
>   Thank
> 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?

Bugs like this largely get ignored as they contain no information, no 
backtrace, or any other useful information. They are not ignored 
maliciously, they are ignored because the next bug along did contain 
complete information, so that bug got handled first.

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

This is the exact very audience we need 'testing' experiments.

Where in the bug report did the end user express their frustration or 
dissatisfaction that the cache module didn't work? Nowhere. They tried 
it on Windows, it didn't work for them, and they took time out to log a 
bug for it. There are no "me too"s attached to the report, so it's safe 
to assume the problem went away.

The point is an end user bothered to try it out and send feedback, and 
that is why we have cache today.

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

If nobody is standing behind the module, it will mean that nobody will 
object if someone says "perchild is causing grief and seems unsupported, 
any objection to putting it in an attic?".

You are 100% right that experimental is not the place for abandoned modules.

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

People were disappointed because v2.0 didn't have a cache full stop. The 
actual cache module only came much later.

v2.0 was a _big_ jump from v1.3. The v2.0 proxy was a complete rewrite 
using an entirely new architecture, and when v2.0 went GA cache was 
nowhere near ready, however cache was not considered a showstopper.

> 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 :)

The trouble with new modules is that no matter how meticulously you went 
over it, there is always one platform that doesn't work (in the case of 
LDAP, the PITA platform was Windows), but if you don't release the code 
in case it might not work, it will never reach the people who have the 
resources to make it work.

There is a natural threshold of effort above which people are far less 
likely to take the time out to help. An svn update is easy. Checking out 
and building an entirely separate sandbox is above the threshold for 
most people.

Witness the proxy changes to v2.0 in the proxyreq branch. The nature of 
the changes meant that a branch was 100% necessary, but the side effect 
was that it took far longer to review the changes than other code in the 
server. It amounted to a significant deviation from normal development 
patterns to test it properly, and so reduced the audience significantly.

This is why experimental must live. :)


View raw message