On Saturday, May 5, 2001, at 03:45 AM, Greg Stein wrote:
> Ah. I think I understand where you're going. There are two RMs:
>
> 1) the httpd RM (releasing the bare bones httpd)
> 2) the "rollup" RM (releasing httpd + many modules)
>
> At the moment, RM2 only yanks in mod_proxy.
>
> That feels good to me. RM1 has the largest piece of code, with the
> scariest
> amount of "is this crap stable?" questions to handle. RM2 doesn't have
> to
> deal with that bulk, but just with the (independent) modules that are
> getting rolled up. And presumably, by the time RM2 starts, each of the
> subprojects have performed their own integration testing and bugfixing
> against RM1's release (and they could continue their work after
> dropping off
> a "proxy for httpd 2.0.23" tag in their tree).
>
Exactly. At Platinum, we had never got this bit quite right, so a lot of
work fell back onto the RM. We used the pipelined integration approach
to a single big release, and while it helped individual bits integrate,
it really pushed a lot of the interop and side effect stuff out the end
of the pipeline to fall into the RM's lap (or the test people). That's
what I'd like to avoid here. This was with a core project and a couple
of dozen "subprojects".
> And one day, RM2 goes away because we have a CPAN-like thing.
Yep, and thinking through the subproject module "cutting" process will
let us do that cleanly, as well as leaving other distrib options open if
we choose to take them. Plus, subprojects can still do interim updates
into their own /dist areas, if they take sufficient care.
> Presuming I haven't misunderstood, that sounds great. (it was hard to
> tell
> what was the end goal thru that long thread...)
>
Yes, that's precisely it. It was getting hard for me, too, because this
idea really started to get concrete back at the [VOTE] thread.
Actually, I think we starting to talk about this a little at the
hackathon. 8^)
The beta process we're in seems a decent time to wring this idea out, at
least for the proxy. That puts us in lots better shape once we add more
modules to the rollup mix.
Chuck
> On Sat, May 05, 2001 at 03:16:01AM -0400, Chuck Murcko wrote:
>> Sure, as long as there's only one module doing this. Once you have a
>> number of modules doing this it's a pipeline, which slows the process
>> down. And the only version that'll really matter to people is the one
>> that pops out of the end of the pipeline. Is more reliable for
>> integration?
>>
>> I'd think to make the integration a parallel process that spreads the
>> work out among the subproject owners (you integrate your subproject
>> with
>> the current rollup release, not the httpd-only release already done).
>> That removes most of the problems from the RM because he gets back a
>> functioning, integrated httpd source tree, with instructions on
>> assembling from CVS tags. Httpd core code can't be touched because it's
>> already released. That's what makes the parallel bit possible,
>> subprojects can't touch the core code until next httpd release, right?
>>
>> So it makes sense to make this part of a rollup release with many
>> subprojects integrated. Leaving the integration headaches to the httpd
>> RM would be insane, as you say. This spreads individual subprojects
>> responsible for integrating with the whole release, not just httpd and
>> its dependencies. It also lets you check interoperability, such as
>> between mod_rewrite (or mod_include) and mod_proxy.
>>
>> For now, it's just fine for mod_proxy to roll its own release. We still
>> need to think about the long term solution. Make sense?
>>
Chuck Murcko
Topsail Group
http://www.topsail.org/
