Greg Stein wrote:
> Bleck. That is exactly what I was trying to say we *don't* do. That is just
> adding a bunch of overhead onto the RM. Just as we got the RM's job all nice
> and simple, this goes and monkeys it back up.
Ok, stepping back a bit - I am not making myself clear at all. What I'm
proposing has the following requirements:
- There is only ever one release of Apache to the outside world, called
apache-2.x.x.tar.gz. This release is has httpd-core, APR, APR-util,
proxy, rewrite, etc in one archive. End users are therefore never
confused about what's in the pack. End user's lives are not made a
misery by having to pull modules from here there and everywhere before
they can build Apache (been there done that).
- The rollup RM should never know or care whether any of the modules
work with the current release of Apache. They can't, so they won't. All
they do is pick up the most recent stable versions from some or other
directory somewhere. No headaches, no responsiblity, just watch the roll
script do all the work.
- The modules RMs should be responsible for making sure that their
module in the stable directory works at any given time. No coordination
with the rollup RM is necessary at all - if the module ain't broke no
need to fix it.
> The httpd RM happens to roll APR(UTIL) because Apache simply can't work
> without them. It is rather easy to test whether Apache works or not. When
> you start throwing in independent, optional modules, the RM then has to know
> a lot more about what is going on.
The RM is not responsible for making the modules work, all he is
responsible for is copying the modules into the rollup tree and rolling
the release. If this stage breaks, it is the responsiblty of the module
owners to fix it.
> The httpd RM should just release a plain httpd. The rollup should be
> separate, and handled by a rollup RM.
As long as the "plain" httpd never becomes an official release.
Releasing both "A" and "A"+"B" is silly, as "A"+"B" includes "A". It's
just extra confusion and extra work.
If "A" remains part of the internal build process it will be fine - "A"
will become yet-another-module-to-be-integrated-by-the-RM.
> The modules key off httpd, never the other way around. We don't build httpd
> to match a specific release of mod_proxy.
>
> Instead, you release an httpd. *THEN* the modules ensure they work with
> *that* released version. The modules have a solid, fixed target to shoot
> for. *THEN* you release a rollup.
This is the same problem, just the other way around. Suddenly the
modules must now wait for Apache to be released - yuck.
Nobody should be waiting for anybody. At any given moment in time a
module in a stable rollup directory should work with the latest bleeding
egde HTTPd. If it does not, it must be fixed.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
