>>> On Wednesday, September 21, 2005 at 9:19 am, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > > 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). > 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?
So you took one bug and tried to apply its effects across the board. What about all of the bugs that were helpful in making mod_cache usable? The worst that happened is that we ended up with a bug in bugzilla that needed to be cleaned out. So what? > 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. I believe that a module like mod_cache absolutely belongs in svn and the release. In the case of mod_cache there was a community behind it and it demanded visibility and testing in order to move it to a non-experimental state. If it had been pushed off to some sandbox somewhere, our users would still be waiting for it. That is a lesson that was learned from auth_ldap. Granted not all modules are like mod_cache. But that is something that should be decided on a case by case basis through discussion on the list. > 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. We aren't here to make everybody happy all of the time. So it pissed off some users. Those that stuck with it, helped to produce something that is now a standard module. The important point is that mod_cache got the feedback it needed to improve it. Even if that feedback came from a pissed off user. > > 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 :) > > Bill I haven't seen experimental being abused in this way in the past so why would you assume that it would be abused this way in the future. The list still has to vote and decide what goes into experimental and what doesn't. Just like any other project decision, you have to trust the collective to do the right thing. Brad
