Message-ID: <34D64F8A.4E13D9CC@Golux.Com>
Date: Mon, 02 Feb 1998 17:58:18 -0500
From: Rodent of Unusual Size <Ken.Coar@Golux.Com>
Organization: The Apache Group
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: apache/linux modules
References: <Pine.LNX.3.96.980202162834.23774U-100000@alien.redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Cristian Gafton wrote:
> 
> Try to look at this from a distribution maintainer point of view. We'd
> like to be able to ship aoache modules for Red Hat systems to include
> postgres support, other cool stuff, without having to rebuild the apache
> binary package every time... It is not only cool, buty it will make apache
> easy to deploy on a lot of other cases (think about products like miniSQL,
> mySQL, Solid server, etc, shipping their version of apache module and all
> you have to do is to stick it into a directory and apache will start using
> it..)

Perhaps I'm speaking out of turn here, but it seems to me that
RedHat does *not* have a very good record when it comes to shipping
a working Apache Web server with no more bugs than in what *we*
release.  I recall a lot of reports of strange problems that were
eventually traced back to the RedHat-specific distribution.  And
for the last couple/few releases of RedHat, at that.  I don't know
how many of the resulting "it doesn't work" reports go to RedHat,
but a distressing number of them come our way.

Adding value is good.  But the flexibility you tout in the above
paragraph seems to me to be adding numerous dimensions to how the
distribution could be screwed up.  Which means more bug reports for us.

Someone "sticks the module into a directory" and suddenly the server
starts misbehaving.  Worse, they stick it in the directory before
starting the server for the first time, so when it breaks it looks
like it's always been that way.  No, thanks - that makes our
software look like a crock of that-which-fertilises even though
it's not our fault.  I much prefer a situation in which adding
new modules requires active work by the Webmaster so its quite aware
of the change.  Then there's the potential that the Webmaster will
make the connexion between the change and the brokenness.  Unlikely,
I know - but a greater probability, I think, than in the "drop-in
module" scenario.

Perhaps I'm gun-shy - I've been in the 'helpline' business for a
loooong time.  The number of ways in which end-users can consume
support time beggars the imagination.

Just FWIW, and with no animosity.

#ken	P-)}
#ken	P-)}