httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Issues for 2.1.8
Date Wed, 21 Sep 2005 17:20:32 GMT


>>> On Wednesday, September 21, 2005 at 9:19 am, in message
<43317A13.9030800@rowe-clan.net>, wrowe@rowe-clan.net 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 


Mime
View raw message