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?
On Wednesday, May 2, 2001, at 07:32 PM, Greg Stein wrote:
> Are you guys talking about the httpd RM? Or the proxy RM?
>
> This is a huge burden on the httpd RM. Today, anybody can pop out a
> release
> in pretty short order. With all of the legwork you guys seem to be
> adding to
> the httpd RM, I can't see that as being possible any more.
>
> Can we *please* reconsider the httpd RM drops a release to dist/httpd/.
> The
> proxy RM verifies stability and drops a release to dist/proxy/.
>
> Each RM knows *their* code and how to ensure *their* code is stable. I
> don't
> think it is workable to have the httpd RM need to know the stability of
> the
> proxy code.
>
> Cheers,
> -g
>
> On Wed, May 02, 2001 at 04:10:20PM -0400, Chuck Murcko wrote:
>> OK, but we still need to maintain the old releases somehow other than
>> as
>> CVS tags, no? I.e.; where does the packaged 1.3.19 proxy distribution
>> go
>> when we move on to 1.3.20?
>>
>> The stable subdirectory is actually supposed to be the same release
>> number the httpd distrib is cut with, to allow scripting the work. So
>> the directories only get created with a new release. When 2.0.18 proxy
>> releases, you make the 2.0.19 dirs and drop code there. Some other
>> naming rule might work better.
>>
>> The subproject people could get a serial "token" from the release
>> manager and pass this among themselves while they integrate, and last
>> subproject guy hands it back to the RM saying "this is a rollup release
>> candidate".
>>
>> We can specify a time (24-48 hours? Less?) to complete each subproject
>> integration to keep the process moving along.
>>
>> If each subproject is set up (ready to integrate) already to put itself
>> into a httpd source tree, the RM can just run a rollup script and build
>> the whole source distrib (with all the subproject modules) at once.
>> This
>> is less safe than the first alternative if subprojects ever change
>> files
>> in the core when they integrate.
>>
>> Folks would build the binary distribs from that rollup source distrib,
>> I'd imagine.
>>
>> On Wednesday, May 2, 2001, at 08:54 AM, Graham Leggett wrote:
>>
>>> Chuck Murcko wrote:
>>>
>>>> 1) tag releases of httpd subprojects intended for release with the
>>>> tagname
>>>> that httpd uses for the same release (simplifies CVS assembly of
>>>> src)
>>>>
>>>> 2) packaged release drops go into a subdir named by the httpd release
>>>> they go
>>>> with; i.e., httpd, so httpd-proxy/stable/apache-1.3.20 or
>>>> httpd-proxy/stable/httpd-2.0.
>>>
>>> The trouble is that this means the subproject people are going to have
>>> coordinate with the RM to create the directory with the release number
>>> in it all the time, which will be a pain.
>>>
>>> How about a /httpd-proxy/stable/ directory containing the latest fixed
>>> code in it? The development could then happen in a /httpd-proxy/devel/
>>> directory, and when the new development code is stable, the changes
>>> get
>>> committed to the /stable/ tree...?
>>>
>>> Patches would then go in a /httpd-proxy/patches/apache-1.3.20/
>>> directory.
>>>
>>> The RM will then pull in the code from the /stable/ directory at roll
>>> time - the module people (us) won't need to do anything except make
>>> sure
>>> whatever is in /stable/, is stable.
>>>
>>> Regards,
>>> Graham
>>> --
>>> -----------------------------------------
>>> [EMAIL PROTECTED] "There's a moon
>>> over Bourbon Street
>>> tonight..."
>>>
>>>
>>
Chuck Murcko
Topsail Group
http://www.topsail.org/
>
> --
> Greg Stein, http://www.lyra.org/
>
