Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat for Tomcat 3.3

[jean-frederic clere <jf...@fujitsu-siemens.com>]

+1

Larry Isaacs wrote:
> 
> I agree with Costin's suggestion to remove the Apache 2.0
> version of mod_jk from jakarta-tomcat for Tomcat 3.3.
> This would occur after any bug fixes missing from
> jakarta-tomcat-connectors were ported.
> 
> It makes much more sense to have it live only in
> jakarta-tomcat-connectors where it can quickly respond
> to changes. I don't plan much maintenance on the connectors
> once Tomcat 3.3 is released.
> 
> VOTE:
> 
> [ ] +1 REMOVE: Apache 2.0 mod_jk should be removed from
>        jakarta-tomcat for Tomcat 3.3
> [ ] -1 KEEP: Apache 2.0 mod_jk should be kept in
>        jakarta-tomcat for Tomcat 3.3
> 
> My vote is +1.
> 
> Cheers,
> Larry
> 
> > -----Original Message-----
> > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > Sent: Friday, September 07, 2001 2:17 PM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: RE: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0
> > mod_w ebapp.c
> >
> >
> > On Fri, 7 Sep 2001, GOMEZ Henri wrote:
> >
> > > Don't forget that many of us must evaluate
> > > a KNOWN Apache 2.0 in real environnement.
> > > The most known are Apache sites which use the released
> > > version 2.0.24 :)
> > >
> > > We could do that a each release (2.0.24/2.0.25) but
> > > not in real-time ;)
> >
> > Probably the correct solution is somewhere in the middle. I agree with
> > Henri that using the HEAD is extremely difficult for both
> > developers and
> > potential users who want to help testing or just evaluate
> > 2.0+jk. However
> > sticking with an old snapshot and not testing with the HEAD
> > is also bad.
> >
> > Having more frequent 'stable' snapshots of 2.0 would be IMHO the best
> > solution, and keeping jk in sync with the latest snapshot
> > wouldn't be that
> > difficult. At least we could get reproductible behavior - and more
> > determinism.
> >
> > So my proposal for jk would be to use snapshots - regardless
> > of alpha or
> > beta status. When the dust settles on a 2.0 change and a new
> > alpha/beta
> > snapshot is released - we can update our APIs.
> >
> > BTW, giving the amount of change in 2.0 - what about removing
> > the 2.0 jk
> > connector from 3.3, and relying on j-t-c for a 2.0 connector ?
> >
> > Right now the jk code in jakarta-tomcat is supposed to be
> > 'stable', and
> > only clear bug fixes are ported back. The 2.0 module can't be
> > considered
> > stable ( since it changes all the time ) - and what could be
> > released with
> > 3.3 will be certainly out of sync the next day.
> >
> > Should we call a vote on this ?
> >
> > Costin
> >
> >
> >