my only issue with moving proxy ( and rewrite ) to sub-projects
is their visibilty, and future maintenance.
These 2 modules are heavily used in 'large' websites, and for
me they hold the same importance as mod_include.
are people just worried about there being a bug-fix in a module,
which forces a roll of the entire application?
..Ian
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 18, 2001 11:29 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] mod_proxy in?
>
>
> From: "David Reid" <[EMAIL PROTECTED]>
> Sent: Wednesday, April 18, 2001 12:50 PM
>
>
> > Well, why not do the same as we've done for APR? I don't
> see why mod_proxy
> > can be "bundled" in the same way can't it? It seems to
> make sense as both
> > an included "entity" and a seperate project.
>
> What I suggested as a roll-up? Of course, we can release
> these together, including
> any new http/https/protocol/proxy/auth and whatnot!
>
> I'm suggesting that given an 8 month pause in 1.3 releases
> last year, with several
> simple win32 proxy fixes dropped in, we dropped the ball.
> Proxy was fixed, but there
> was no push to reroll all of apache-1.3.
>
> A sub-project aught to be able to release as it is ready. If
> proxy is ready for a
> 'release' today, then roll one for 2_0_16 (our last beta) and
> let folks bring it up
> to date. 2_0_17 is now broken for some platforms shutdown,
> so they will be waiting
> a while longer to play with proxy. This is the
> wrongheadedness of rolling in the
> entire, complex kitchen sink into httpd-2.0.
>
> When we roll 2_0_18, we aught to roll in the last good tag of
> proxy. This all
> implies an independent sub-versioning schema for these apache
> sub-projects, and
> I don't have an answer off the top of my head. Perhaps those
> who revamped the
> tag/roll/build/release schema have a way this could play well
> (and perhaps good
> arguments against.)
>
> Bill
>
>
>
>
>
