httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jess M. Holle" <>
Subject Re: Vote: mod_jk connector in /experimental
Date Mon, 09 Sep 2002 15:00:35 GMT wrote:

>On Tue, Sep 03, 2002 at 09:51:20AM -0500, Jess M. Holle wrote:
>>It would be nicest of all to have builds of each version of the core for 
>>each platform -- and pluggable binaries of all the extra modules for 
>>each version/platform as well.
>Eergh.. this sounds like a maintenance nightmare.

If the builds are automated, then there's no maintenance in producing 
new binaries.  If the builds don't work, then the releases should not be 

>>This could be cranked out by automated 
>>scripts as a release criteria/requirement, i.e. it's not a release until 
>>everything builds on all platforms with the automated scripts (and 
>>ideally passes some basic tests on all of them too).
>I can almost guarantee you this will translate to "we will never again have a
>There are still several significant official apache distribution modules from
>1.3 which do not yet work under the current 2.0 line.
I was not referring to modules from 1.3 that don't work with 2.0. 
 Rather I was talking about modules which ostensibly work against 1.3.x 
or 2.0.x respectively.

>Considering that we're
>talking about creating a repository which presumably will be containing not
>only all of this stuff but lots of third-party modules with various levels of
>maintenance and stability, requiring that they all compile and work before
>releasing a new version of httpd is, frankly, insane.
Actually, you raise a good point.  Third party modules should be 
referenced by hyperlink and the party involved should be e-mailed to 
notify them when a new build label is produced, but the Apache group 
cannot take responsibility for 3rd-party modules.  They can, however, 

   1. Something like, but with links direct
      to download directories wherever possible.
   2. Minimalistic coordination with such 3rd-parties to allow/encourage
      them to rebuild with each Apache build.

Note that I am assuming a DSO-based distribution.

>Personally, what I would like to see is something along the following lines:
>1.  A core Apache distribution containing a minimal server.  This would contain
>the core code and the few modules required to get the basic HTTPD behavior
>everybody expects from any server (serve files off a disk, run CGIs, and not
>much else).  This would be useful for those wanting a "lean and mean" httpd
>server, or for those who want to build everything custom from the module
>repository.  It would also make it easy to release core updates in a timely
>fashion, as new releases of this package could be made with a minimum of
>modules needing to be updated/tested.
>2.  An "enhanced" Apache distribution, containing everything from the minimal
>distribution, plus a bunch of really commonly used modules.  This would be
>equivalent to what generally gets distributed now.  Criteria for what modules
>get bundled into this should be based primarily on demand (only modules that
>lots of people out in the real world need and use), and of course there would
>be a requirement that any included modules must have people willing and able to
>actively develop and debug them in a timely fashion, so that if something
>breaks, it doesn't seriously slow down the release schedule (without good
>reason).  It would be nice if releases of this package corresponded roughly to
>releases of the core package, but if a core change was made which required
>updating a lot of stuff, the core package could be released first, while work
>is still going on on updating all the other modules in this package to work
>with the new core before the enhanced package goes out the door.
>3.  A repository of all apache modules (including all the ones from the
>enhanced distribution, and from everybody else out there in the world) in a
>consistent, well-defined form with a modular build system for the core which
>you can just drop them into.  Ideally, I would like to be able to download one
>of the above two distributions, unpack the source, cd into the source
>directory, and then unpack mod_foo.tar.gz and mod_bar.tar.gz (obtained from the
>repository), run configure/make, and get a server which includes the foo and
>bar modules just as if they'd been part of the initial distribution.  With a
>well-defined module distribution file format and a build system which
>automagically supported modular-inclusions, this shouldn't be too hard to
I agree up until the point where you say configure/make.  I have little 
trouble with this at this point personally, but after you watch the 
uninitiated do this for a while -- especially given some esoteric 
misconfiguration in their build support software (e.g. gcc) you come to 
appreciate *binary* distributions.

Jess Holle

View raw message