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 wasill-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. :) Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
