[EMAIL PROTECTED] 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.
Why?

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 done.
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
release."

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, provide:
  1. Something like http://modules.apache.org/, 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
achieve.
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

Reply via email to