RE: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c

[GOMEZ Henri <hg...@slib.fr>]

>This will need to change when my next patches in the webapp 
>library go in,
>as Apache will be able to serve static files when possible...
>
>Also, since Apache 2.0 is not final yet, I would remove all
>MODULE_MAGIC_NUMBER checks, and _require_ for the module to be 
>built with
>the latest HEAD out of CVS... I don't care at this point about 
>2.0 backward
>compatibility....

I didn't agree with that Pier, we must try to keep compatibility 
with previous release of Apache 2.0, since there IS STILL NO
official release. 

Many users are still using Apache 2.0.24-alpha (including myself), 
or even 2.0.18-beta (including IBM iSeries team porting Apache 2.0).

Let avoid questions in user-list asking about which version of 
Apache 2.0 to be used, or why we couldn't compile the module
against a running (even if obsolete) Apache 2.0....

That's a part of the problem in mod_webapp with APR.
 
>I'd do something like at the top of the file, and move the 
>version to check
>against accordingly, until 2.0 doesn't get final.
>
>#if (MODULE_MAGIC_NUBER_MAJOR < 20010808)
>#error ERROR: You need the latest Apache 2.0 code to compile
>#endif

Please mod_jk commiters, in JT and JTC, keep care of 
previous releases and still use MODULE_MAGIC_NUBER_MAJOR
when needed.

As soon as Apache 2.0 will be released, we'll clean code by 
dropping all that controls, but until that we must keep 
compatibility with at least latest beta (2.0.18-beta)

Hi Ho.

Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c

[Ryan Bloom <rb...@covalent.net>]

On Thursday 06 September 2001 18:06, Justin Erenkrantz wrote:
> On Fri, Sep 07, 2001 at 01:52:50AM +0100, Pier Fumagalli wrote:
> > Since there is no official release of httpd-2.0, I am confident that
> > nobody will actually care unless they're testing something... And by
> > "testing" good practice says "get the HEAD of CVS and try it out yourself
> > if it doesn't work". Development happens on "head" and if someone forks
> > off for a little while to do some porting to some weird operating
> > systems, at the end those changes will have to be integrated with HEAD,
> > so, there's no point in sticking with backward compatibility AT THIS
> > POINT.
>
> +1 to what Pier said.  (Ryan may chip in here too...)
>
> If you are using anything other than HEAD for httpd-2.0, I don't
> care much about any bug reports you may have.  The odds are that it'd
> either be fixed or broken in a different manner.  =)  -- justin

Don't try to mainain backwards compat in 2.0.  We aren't even trying yet.
Every release of 2.0 other than head has a serious problem, either a 
memory leek, or a security hole, or it can crash the machine.

IF your not using HEAD of httpd-2.0, you have a problem.  :-)

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c

[Pier Fumagalli <pi...@betaversion.org>]

"Justin Erenkrantz" <je...@ebuilt.com> wrote:

> On Fri, Sep 07, 2001 at 01:52:50AM +0100, Pier Fumagalli wrote:
>> Since there is no official release of httpd-2.0, I am confident that nobody
>> will actually care unless they're testing something... And by "testing" good
>> practice says "get the HEAD of CVS and try it out yourself if it doesn't
>> work". Development happens on "head" and if someone forks off for a little
>> while to do some porting to some weird operating systems, at the end those
>> changes will have to be integrated with HEAD, so, there's no point in
>> sticking with backward compatibility AT THIS POINT.
> 
> +1 to what Pier said.  (Ryan may chip in here too...)

Yeah, I would like to hear what he thinks...

> If you are using anything other than HEAD for httpd-2.0, I don't
> care much about any bug reports you may have.  The odds are that it'd
> either be fixed or broken in a different manner.  =)

You would have not better explained my thoughts in a better way...

> -- justin

Who I respect so much after he committed that patch to get rid of MM un APR
land, and saved me at least 2 headaches :) :) :) :)

    Pier

Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c

[Justin Erenkrantz <je...@ebuilt.com>]

On Fri, Sep 07, 2001 at 01:52:50AM +0100, Pier Fumagalli wrote:
> Since there is no official release of httpd-2.0, I am confident that nobody
> will actually care unless they're testing something... And by "testing" good
> practice says "get the HEAD of CVS and try it out yourself if it doesn't
> work". Development happens on "head" and if someone forks off for a little
> while to do some porting to some weird operating systems, at the end those
> changes will have to be integrated with HEAD, so, there's no point in
> sticking with backward compatibility AT THIS POINT.

+1 to what Pier said.  (Ryan may chip in here too...)

If you are using anything other than HEAD for httpd-2.0, I don't 
care much about any bug reports you may have.  The odds are that it'd
either be fixed or broken in a different manner.  =)  -- justin

Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0mod_webapp.c

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

Pier Fumagalli wrote:
> 
> "jean-frederic clere" <jf...@fujitsu-siemens.com> wrote:
> >>
> >> I could stick with the "last official tarball" since that's an easy piece of
> >> thing to download. So, if the latest version is 2.0.18 alpha (don't even
> >> know since I use HEAD),
> >
> > The is 2.0.25 (Thank STATUS!). 20010808 is a date...
> 
> I don't know about status, but the latest one is 2.0.18 (Alpha) posted in
> June (see http://www.apache.org/dist/httpd/)

No it is: http://dev.apache.org/dist/ otherwise you are very far from the
head...

> 
> > I added the #ifdef to Ryan's patch. And I would keep them until Apache-2.0
> > releases a beta.
> 
> Well, we had betas coming out already, 2.0.16 was a beta, and then the next
> releases were labeled alpha again... Release naming of HTTPd AFAICS depends
> on the level of "trustedness" of the code in the moment of releasing.
> 
> > Apache-2.0 is still changing a lot. (HEAD may broke things like external
> > modules or be broken for some hours).
> 
> That's good... That's exactly what I want... If a new HEAD of httpd breaks
> my module in compilation because I didn't update it, well, then it's my
> fault for not keeping up to date with it... And as I said, let's screw
> backwards compatibility until the code is labeled as FINAL, or something at
> least a little bit closer to it... Right now, the right thing is stick with
> HEAD...
> 
> > I am normaly testing using HEAD. (that is why I am known on
> > dev@httpd.apache.org ;-))
> 
> As anyone else... Everyone uses HEAD...
> 
> > We cannot tell a TC user to update his Apache-2.0 to the lastest version each
> > time there is a new version, he probably wants to test TC not httpd. But we
> > should warn him when he is not using the lastest httpd-2.0 version.
> 
> Yes, we should... I believe that if someone wants to try out the WebApp
> module for 2.0, he'll have to get the latest version available at the
> moment... We're DEVELOPING the sucker, we're not (yet) supporting it...
> (well, both projects HTTPd _and_ WebApp)

Not everyone in TC are specialists of PERL/autoconf/C and able to fix httpd-2.0
or APR code (specialy libtool/autoconf).
I DO think we have to offer a minimalistic support on already installed
httpd-2.0. To give a change to the user so he starts testing (That is easy then
to tell try why version x.y.z).

By the way I am not going to support 2.0.18.

> 
> > So I am -0 for an error message and +1 for a warning.
> 
> I'm way +1 on the error message... :)
> 
>     Pier

Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_webapp.c

[Pier Fumagalli <pi...@betaversion.org>]

"jean-frederic clere" <jf...@fujitsu-siemens.com> wrote:
>> 
>> I could stick with the "last official tarball" since that's an easy piece of
>> thing to download. So, if the latest version is 2.0.18 alpha (don't even
>> know since I use HEAD),
> 
> The is 2.0.25 (Thank STATUS!). 20010808 is a date...

I don't know about status, but the latest one is 2.0.18 (Alpha) posted in
June (see http://www.apache.org/dist/httpd/)

> I added the #ifdef to Ryan's patch. And I would keep them until Apache-2.0
> releases a beta.

Well, we had betas coming out already, 2.0.16 was a beta, and then the next
releases were labeled alpha again... Release naming of HTTPd AFAICS depends
on the level of "trustedness" of the code in the moment of releasing.

> Apache-2.0 is still changing a lot. (HEAD may broke things like external
> modules or be broken for some hours).

That's good... That's exactly what I want... If a new HEAD of httpd breaks
my module in compilation because I didn't update it, well, then it's my
fault for not keeping up to date with it... And as I said, let's screw
backwards compatibility until the code is labeled as FINAL, or something at
least a little bit closer to it... Right now, the right thing is stick with
HEAD...

> I am normaly testing using HEAD. (that is why I am known on
> dev@httpd.apache.org ;-))

As anyone else... Everyone uses HEAD...

> We cannot tell a TC user to update his Apache-2.0 to the lastest version each
> time there is a new version, he probably wants to test TC not httpd. But we
> should warn him when he is not using the lastest httpd-2.0 version.

Yes, we should... I believe that if someone wants to try out the WebApp
module for 2.0, he'll have to get the latest version available at the
moment... We're DEVELOPING the sucker, we're not (yet) supporting it...
(well, both projects HTTPd _and_ WebApp)

> So I am -0 for an error message and +1 for a warning.

I'm way +1 on the error message... :)

    Pier

Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_webapp.c

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

Pier Fumagalli wrote:
> 
> "GOMEZ Henri" <hg...@slib.fr> wrote:
> >
> > I didn't agree with that Pier, we must try to keep compatibility
> > with previous release of Apache 2.0, since there IS STILL NO
> > official release.
> >
> > Many users are still using Apache 2.0.24-alpha (including myself),
> > or even 2.0.18-beta (including IBM iSeries team porting Apache 2.0).
> 
> Since there is no official release of httpd-2.0, I am confident that nobody
> will actually care unless they're testing something... And by "testing" good
> practice says "get the HEAD of CVS and try it out yourself if it doesn't
> work". Development happens on "head" and if someone forks off for a little
> while to do some porting to some weird operating systems, at the end those
> changes will have to be integrated with HEAD, so, there's no point in
> sticking with backward compatibility AT THIS POINT.
> 
> I could stick with the "last official tarball" since that's an easy piece of
> thing to download. So, if the latest version is 2.0.18 alpha (don't even
> know since I use HEAD),

The is 2.0.25 (Thank STATUS!). 20010808 is a date...

> I could agree to have some ifdefs in the code to
> cope with the differences between "latest tarball" and "head".
> 
> All this, of course, UNTIL an official final version comes out, that's when
> I'll start caring about backward compatibility.
> 
> That's my idea, but I would love to hear the other contributors to the
> WebApp module to tell me what they think, Ryan, J.F., Colin, Thom...

I added the #ifdef to Ryan's patch. And I would keep them until Apache-2.0
releases a beta.

Apache-2.0 is still changing a lot. (HEAD may broke things like external modules
or be broken for some hours).

I am normaly testing using HEAD. (that is why I am known on dev@httpd.apache.org
;-))

We cannot tell a TC user to update his Apache-2.0 to the lastest version each
time there is a new version, he probably wants to test TC not httpd. But we
should warn him when he is not using the lastest httpd-2.0 version.

So I am -0 for an error message and +1 for a warning.
 
> 
> > Let avoid questions in user-list asking about which version of
> > Apache 2.0 to be used, or why we couldn't compile the module
> > against a running (even if obsolete) Apache 2.0....
> 
> Like, you've answered a lot of questions on tomcat-user about the WebApp
> module :) :) :) That's a task I'm handling, and I believe I've been pretty
> good at. There's no unanswered question on the WebApp module on the users
> list. (In comparison to...)
> 
> > That's a part of the problem in mod_webapp with APR.
> 
> Choosing APR has been my decision from the beginning. If you guys didn't
> want to do it, why not voting -1 when I dropped the code in CVS? Now it's
> there, I believe it's good. You might not like it, as I don't like what
> you're doing, but, hey, we're forced to coexist on the same mailing list.
> 
> So, as I don't piss you off on what you're doing, please, you do the same.
> :) :) :) :) :)
> 
> Thanks...
> 
>     Pier

Re: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c

[Pier Fumagalli <pi...@betaversion.org>]

"GOMEZ Henri" <hg...@slib.fr> wrote:
> 
> I didn't agree with that Pier, we must try to keep compatibility
> with previous release of Apache 2.0, since there IS STILL NO
> official release.
> 
> Many users are still using Apache 2.0.24-alpha (including myself),
> or even 2.0.18-beta (including IBM iSeries team porting Apache 2.0).

Since there is no official release of httpd-2.0, I am confident that nobody
will actually care unless they're testing something... And by "testing" good
practice says "get the HEAD of CVS and try it out yourself if it doesn't
work". Development happens on "head" and if someone forks off for a little
while to do some porting to some weird operating systems, at the end those
changes will have to be integrated with HEAD, so, there's no point in
sticking with backward compatibility AT THIS POINT.

I could stick with the "last official tarball" since that's an easy piece of
thing to download. So, if the latest version is 2.0.18 alpha (don't even
know since I use HEAD), I could agree to have some ifdefs in the code to
cope with the differences between "latest tarball" and "head".

All this, of course, UNTIL an official final version comes out, that's when
I'll start caring about backward compatibility.

That's my idea, but I would love to hear the other contributors to the
WebApp module to tell me what they think, Ryan, J.F., Colin, Thom...

> Let avoid questions in user-list asking about which version of
> Apache 2.0 to be used, or why we couldn't compile the module
> against a running (even if obsolete) Apache 2.0....

Like, you've answered a lot of questions on tomcat-user about the WebApp
module :) :) :) That's a task I'm handling, and I believe I've been pretty
good at. There's no unanswered question on the WebApp module on the users
list. (In comparison to...)

> That's a part of the problem in mod_webapp with APR.

Choosing APR has been my decision from the beginning. If you guys didn't
want to do it, why not voting -1 when I dropped the code in CVS? Now it's
there, I believe it's good. You might not like it, as I don't like what
you're doing, but, hey, we're forced to coexist on the same mailing list.

So, as I don't piss you off on what you're doing, please, you do the same.
:) :) :) :) :)

Thanks...

    Pier